Hi Apollon,
On Sun, Sep 29, 2013 at 06:49:41PM +0300, Apollon Oikonomopoulos wrote:
> 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).
Interesting, I always thought the relative order between -L and -l was
what matters. But you're right and "man ld" is clear on this point. This
is particularly annoying since it basically means that there's no way to
have multiple paths with overlapping libraries, which is becoming more
and more common these days.
> 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.
Yes, that's exactly what is happening.
> 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.
That's problematic. The issue was created by the addition of pcre-config
because some people could not build on their systems in the past. The whole
mess started with the lib64 subdir that broke basically every software
relying on $FOO/lib. So some users had PCRE in /usr/local/{include,lib64}
and could not specify a working PCREDIR. Thus we switched to pcre-config.
And finally since pcre-config is still wrong on some systems (eg: when you
want to use an alternate version such as the JIT-enabled one), we offered
the support for separate PCRE_LIB / PCRE_INC.
So maybe we should in fact stop setting PCREDIR to $(pcre-config --prefix),
which will result in PCRE_INC/PCRE_LIB remaining silent unless PCREDIR is
forced. I suspect the following patch should fix it :
diff --git a/Makefile b/Makefile
index 0529e89..89f9f39 100644
--- a/Makefile
+++ b/Makefile
@@ -544,7 +544,6 @@ ifneq ($(USE_PCRE)$(USE_STATIC_PCRE)$(USE_PCRE_JIT),)
# Forcing PCREDIR to an empty string will let the compiler use the default
# locations.
-PCREDIR := $(shell pcre-config --prefix 2>/dev/null || echo
/usr/local)
ifneq ($(PCREDIR),)
PCRE_INC := $(PCREDIR)/include
PCRE_LIB := $(PCREDIR)/lib
Regards,
Willy
