fix(openssl): pass RANLIB as a make command-line assignment, not an env var

The macOS build now gets all the way through configure and compile — the CC
pin was the missing piece there — and dies in `make install_sw`, one line after
copying libcrypto.a into place:

    install libcrypto.a -> .../3.5.1/lib/libcrypto.a
    llvm-ranlib: error: Invalid option: '-c'
    make: *** [install_dev] Error 1

which is precisely what the RANLIB override exists to prevent. OpenSSL's
`darwin-common` sets `ranlib => "ranlib -c"` (Configurations/10-main.conf:1844)
and PATH resolves `ranlib` to the toolchain's llvm-ranlib, which rejects `-c`.

The override was not taking effect, and that is a regression I introduced when
confining it to macOS: I moved it from `make RANLIB=… install_sw` to
`RANLIB=… make install_sw`. The first is a command-line assignment and beats
the Makefile's own definition; the second is only an environment variable,
which a Makefile assignment overrides absent `make -e` — so it silently did
nothing and the build failed exactly as if it were not there. Restored to the
command-line form, with a comment saying why the position matters.

Also confirmed from the same log that `--libdir=lib` does its job on macOS:
the archive installs to `3.5.1/lib/`, not `lib64/`.

Verified on linux (cold): openssl member passes.

Author: Sunrisepeak

pkgs/c/compat.openssl.lua

@@ -246,15 +246,23 @@ local function _install_impl()
         return false
     end
 
-    -- macOS only: `make install_dev` runs `$(RANLIB) -c`, and the toolchain
-    -- puts llvm-ranlib (which rejects -c) ahead of the system one on PATH.
-    -- Pinning an absolute /usr/bin/ranlib is itself a host assumption, so it
-    -- is confined to the platform that needs it — a Linux container without
-    -- /usr/bin/ranlib would otherwise fail install_sw for no reason.
-    local ranlib = (os.host() == "macosx") and "RANLIB=/usr/bin/ranlib " or ""
+    -- macOS only: Configure bakes `RANLIB = ranlib -c` into the Makefile for
+    -- darwin targets, and the `ranlib` that PATH resolves to is the
+    -- toolchain's llvm-ranlib, which rejects `-c` — install_dev then dies
+    -- right after copying libcrypto.a. Point RANLIB at Apple's own, without
+    -- the flag. Confined to the platform that needs it: a Linux container
+    -- without /usr/bin/ranlib should not fail install_sw for no reason.
+    --
+    -- It MUST be spelled `make RANLIB=… install_sw` and not
+    -- `RANLIB=… make install_sw`. The first is a command-line assignment,
+    -- which beats the Makefile's own; the second is merely an environment
+    -- variable, which a Makefile assignment overrides (absent `make -e`), so
+    -- the override silently does nothing and the build fails exactly as if it
+    -- were not there.
+    local ranlib = (os.host() == "macosx") and " RANLIB=/usr/bin/ranlib" or ""
     if not run("make install_sw", logf, string.format(
         "cd %s && %s%s install_sw >> %s 2>&1",
-        sh_quote(srcroot), ranlib, make, sh_quote(logf))) then
+        sh_quote(srcroot), make, ranlib, sh_quote(logf))) then
         return false
     end