Opened 16 months ago

Last modified 16 months ago

#1765 new enhancement

configure is fragile in finding system libraries

Reported by: nieder@… Owned by:
Priority: minor Milestone:
Component: other Version:
Keywords: Cc:
uname -a: Darwin Bubble.fios-router.home 17.7.0 Darwin Kernel Version 17.7.0: Wed Feb 27 00:43:23 PST 2019; root:xnu-4570.71.35~1/RELEASE_X86_64 x86_64
nginx -V: nginx version: nginx/1.14.2
built with OpenSSL 1.1.1b 26 Feb 2019
TLS SNI support enabled
configure arguments: --prefix=/sw --conf-path=/sw/etc/nginx/nginx.conf --error-log-path=/sw/var/log/nginx/error.log --http-client-body-temp-path=/sw/var/lib/nginx/body --http-fastcgi-temp-path=/sw/var/lib/nginx/fastcgi --http-log-path=/sw/var/log/nginx/access.log --http-proxy-temp-path=/sw/var/lib/nginx/proxy --http-scgi-temp-path=/sw/var/lib/nginx/scgi --http-uwsgi-temp-path=/sw/var/lib/nginx/uwsgi --lock-path=/sw/var/lock/nginx/nginx.lock --modules-path=/sw/var/lib/nginx/modules --pid-path=/sw/var/run/ --with-pcre-jit --with-debug --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_v2_module --with-http_xslt_module --with-ipv6 --with-mail --with-mail_ssl_module --with-perl=/usr/bin/perl --with-stream --with-stream_ssl_module --with-threads --user=www --group=www --with-ld-opt='-Wl,-read_only_stubs -Wl,-bind_at_load -fPIE -Wl,-pie -L/sw/lib' --with-cc-opt='-g -O2 -fstack-protector -Wformat -Werror=format-security -fPIE -D_FORTIFY_SOURCE=2 -I/sw/include' --with-perl_modules_path=/sw/lib/perl5/5.18.2


configure uses its own homebuilt scripts to detect system libraries. Currently, this will most likely fail on macOS with Xcode10 if the builder doesn't have Macports installed into /opt/local or is using another package manager. Xcode10 does not install headers into /usr/include (only into /Applications/ So the script in auto/lib/libxslt/conf will fail to find libxslt by not finding libxml2.

Alternatively, the build can find headers from the system install, but use the library from a local install (Fink or MacPorts not in /opt/local) because it's not setting the correct -I flags. In the paste below, -I/sw/include/libxml2 is missing (from a Xcode9 install with /usr/include/libxml2 present).

cc -c -g -O2 -fstack-protector -Wformat -Werror=format-security -fPIE -g -O2 -fstack-protector -Wformat -Werror=format-security -fPIE -D_FORTIFY_SOURCE=2 -MD -I/sw/include -I src/core -I src/event -I src/event/modules -I src/os/unix -I /usr/include/libxml2 -I objs -I src/http -I src/http/modules -I src/http/v2 -I src/http/modules/perl \
		-o objs/src/http/modules/ngx_http_xslt_filter_module.o \

So this build will eventually use headers from /usr/include/libxml2 but link to a different /sw/lib/libxml2.dylib install.

Instead of hardcoding the possible search locations of system libraries, the configure detection subscripts should use pkg-config (or the library included *-config script) whenever possible. Of the detected libraries in auto/lib, geoip, libgd, libxslt, openssl, pcre, and zlib all officially include .pc files from upstream and should be a more foolproof way of detecting their presence and usage flags.

Change History (1)

comment:1 by Maxim Dounin, 16 months ago

Type: defectenhancement
Version: 1.15.x

Thank you for your suggestions.

Using pkg-config (and/or library-provided config scripts, such as pcre-config) is something we've considered. Unfortunately, in many cases using pkg-config is not an option, because it is not available - for example it does not exist on macOS you've mentioned. Further, in some cases the name conflicts with different programs - for example, on FreeBSD pkg-config is a part of the pkg package manager, and pkgconf (if available) needs to be used instead. Not to mention that at least in some cases *.pc files are not properly installed, leading to no information provided by pkg-config even if it is available.

Given the above, currently we are not using pkg-config, and improving configure to use it if available is going to be tricky in terms of compatibility.

Note well that the intention of the automatic detection of various common library paths, as introduced in nginx 0.4.14, was to simplify common use cases. It is not expected to (and cannot) cover all possible cases, much like using pkg-config cannot cover all possible cases as well. If configure cannot detect paths, or you are not happy with paths detected by configure, you can always use --with-cc-opt= and --with-ld-opt= configure arguments to provide any paths instead.

Note: See TracTickets for help on using tickets.