Hi all, On 13:35 Sun 29 Sep , Willy Tarreau wrote: > Yes, and I have fixed this two weeks ago. The problem is that the > "ADDINC" > and "ADDLIB" variables are not suited for passing single-component paths > since they suffix everything. Look what it results in your build log : > > -lcrypt -lssl -lcrypto -L/usr/lib -Wl,-Bstatic -lpcreposix \ > -lpcre -Wl,-Bdynamic -L/tmp/staticlibssl/lib -ldl > > As you can see, -lssl and -lcrypto are looked up in your system path. > > Since commit 9a05945bd0, you now have an explicit set of SSL_INC/SSL_LIB > variables, just like with PCRE, that you can point to your openssl > location. I'm using this to build with a static openssl version, as > this time it's safe, as you can see below :
The real culprit is `-L/usr/lib' in the linker line above, which appears before `-L /tmp/staticlibssl/lib'. Here the relative order *is* important (unlike the relative order of -l and -L flags), and also the fact that /usr/lib is already in the system search path (and shouldn't really appear in a -L option). I should have spotted that earlier on, it was reported to us as Debian bug #722777 [1] and it's there because of USE_PCRE; when USE_PCRE is enabled, and PCREDIR is not specified, PCRE_LIB will be forced to `pcre-config --prefix`/lib (which 99% of the time will be /usr/lib) and included in LDFLAGS. If libssl.so is in that path (which will happen 99% of the time if PCRE is in the system library path and the system does not use multiarch triplets) it will be picked up instead. So in this case, it's the relative position of PCRE vs ADDLIB arguments in the linker command line that causes ADDLIB to be unable to override system libraries by default. The same also goes for PCRE_INC, although gcc is a bit smarter than ld: If the directory dir is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated . By the way, my previous patch on the Makefile worked because it forced ld to only consider static archives for OpenSSL, which were (of course) not present in Debian's /usr/lib. IMHO, we should have a closer look at this, as it has at least caused trouble twice (once with mips builds as per [1], and once now in Julien's system). PCRE_LIB is currently added even on systems it doesn't make any sense on; for example in Debian Wheezy with multiarch, PCRE resides in /usr/lib/x86_64-linux-gnu but the Makefile adds a -L/usr/lib which has nothing to do with PCRE. My guess is that PCRE_LIB/PCRE_INC are not generally needed and should be explicitly specified when desired. Regards, Apollon [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722777
