[PATCH] Configure: link libcrypt when a feature using it is detected

Sergey Kandaurov pluknet at nginx.com
Wed Mar 20 14:57:14 UTC 2024


> On 28 Feb 2024, at 05:23, Piotr Sikora via nginx-devel <nginx-devel at nginx.org> wrote:
> 
> # HG changeset patch
> # User Piotr Sikora <piotr at aviatrix.com>
> # Date 1708977638 0
> #      Mon Feb 26 20:00:38 2024 +0000
> # Branch patch014
> # Node ID 570e97dddeeddb79c71587aa8a10150b64404beb
> # Parent  cdc173477ea99fd6c952a85e5cd11db66452076a
> Configure: link libcrypt when a feature using it is detected.
> 
> Previously, this worked only because libcrypt was added in a separate
> test for crypt() in auto/unix.

Hello, 

The crypt_r() test was added specifically for a missing crypt_r() on
uclibc, which is rare these days: uclibc has just crypt() in libcrypt.
Anyway, crypt_r() is expected to be in the same library as crypt().
That's how it worked in practice: testing crypt_r() uses libcrypt to
pass in all cases, and testing crypt() adds actual -lcrypt as needed.

Currently, it may fail rather theoretically: e.g. crypt_r() is present
in libcrypt, but crypt() is not (it might be in libc, instead).
In this case, given the crypt_r() precedence, linking nginx would
fail due to a missing linking with libcrypt required for crypt_r().

Aside from uclibc, I think the patch is good to improve consistency.
I'd rewrote the description to be more specific:

: Configure: fixed Linux crypt_r() test to add libcrypt.
: 
: Previously, the resulting binary was successfully linked
: because libcrypt was added in a separate test for crypt().

> 
> Signed-off-by: Piotr Sikora <piotr at aviatrix.com>
> 
> diff -r cdc173477ea9 -r 570e97dddeed auto/os/linux
> --- a/auto/os/linux Mon Feb 26 20:00:37 2024 +0000
> +++ b/auto/os/linux Mon Feb 26 20:00:38 2024 +0000
> @@ -228,6 +228,10 @@
>                   crypt_r(\"key\", \"salt\", &cd);"
> . auto/feature
> 
> +if [ $ngx_found = yes ]; then
> +    CRYPT_LIB="-lcrypt"
> +fi
> +
> 
> ngx_include="sys/vfs.h";     . auto/include
> 

-- 
Sergey Kandaurov


More information about the nginx-devel mailing list