RE: Static haproxy/openssl build error
Hi Willy,
>> Like previsouly suggested by Apollon, we could introduce a flag for
>> statically linking openssl, like we have with PCRE (USE_STATIC_OPENSSL?).
>>
>> If we do that, we could also include -ldl automatically when using that USE
>> flag.
>>
>> Thoughts?
>
> I'm a bit hesitant here and am not completely fond of what we did for
> PCRE_STATIC. The problem is that we force -Wl,-Bstatic then -Wl,-Bdynamic,
> and that it breaks full static builds. There's no option in the linker
> like "-Wl,-Bdefault" to say "let's come back to the default model", so
> we have to force "dynamic" by hand at the end of inclusion of the lib
> and complicate the things.
I see; I was not aware of this problem.
> Or maybe we could have a variable "BUILD_MODEL" = {static,dynamic} that
> we use to set the fallback mode and take the correct decisions when adding
> libraries.
You mean maintaining the USE_STATIC_LIBXY approach and use the BUILD_MODEL
variable to fix this problem? Could be a possibility, but its gets more
complex again; perhaps we should rethink the whole USE_STATIC_LIBXY approach
instead? Not sure.
> Anyway, I tend to prefer to let people pass an option to fix their build
> issues than having a few other ones patch the makefile to get rid of
> something that was added for laziness and breaks their build.
Agreed.
Sending the README patch about SSL_INC/SSL_LIB now.
Regards,
Lukas
Re: Static haproxy/openssl build error
❦ 30 septembre 2013 13:01 CEST, Apollon Oikonomopoulos :
>> My version of pcre-config (8.30, also tested with 8.31) includes:
>>
>> libS=
>> if test ${prefix}/lib/x86_64-linux-gnu != /usr/lib ; then
>> libS=-L${prefix}/lib/x86_64-linux-gnu
>> fi
>
> Update:
>
> Debian's 8.31 (testing/unstable) actually does not emit -L using
> pcre-config. I just looked at the source, but did a wrong ./configure.
> The actual script shipping with the package tests /usr/lib against
> /usr/lib. I assume that's the version you're running Vincent, right?
Yes.
--
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)
Re: Static haproxy/openssl build error
On 13:49 Mon 30 Sep , Apollon Oikonomopoulos wrote:
> Hi Vincent,
>
> On 12:19 Mon 30 Sep , Vincent Bernat wrote:
> > For me, pcre-config --libs does not use `-L`. Dunno why this is the
> > case for Apollon.
>
> My version of pcre-config (8.30, also tested with 8.31) includes:
>
> libS=
> if test ${prefix}/lib/x86_64-linux-gnu != /usr/lib ; then
> libS=-L${prefix}/lib/x86_64-linux-gnu
> fi
Update:
Debian's 8.31 (testing/unstable) actually does not emit -L using
pcre-config. I just looked at the source, but did a wrong ./configure.
The actual script shipping with the package tests /usr/lib against
/usr/lib. I assume that's the version you're running Vincent, right?
Apollon
Re: Static haproxy/openssl build error
Hi Vincent,
On 12:19 Mon 30 Sep , Vincent Bernat wrote:
> For me, pcre-config --libs does not use `-L`. Dunno why this is the
> case for Apollon.
My version of pcre-config (8.30, also tested with 8.31) includes:
libS=
if test ${prefix}/lib/x86_64-linux-gnu != /usr/lib ; then
libS=-L${prefix}/lib/x86_64-linux-gnu
fi
So, it seems it tries to be smart, but is not multiarch aware (I'll open
a bug against it). This would obviously work correctly in squeeze,
except that the version in squeeze lacks even this simple test :-)
pkg-config on the other hand works better:
$ pkg-config --libs libpcre
-lpcre
Apollon
Re: Static haproxy/openssl build error
❦ 30 septembre 2013 11:30 CEST, Willy Tarreau : >> I would use `pcre-config --libs` and `pcre-config --cflags` instead. The >> user can still override this on make command line. >> >> PCRE_CFLAGS := $(shell pcre-config --cflags) >> PCRE_LIBS := $(shell pcre-config --libs) > > But these would still cause the issue we're currently facing because > they'll add -L/usr/lib or whatever is in the system path, so that does > not fix the issue. Really I'd rather get rid of pcre-config completely. > Anyway, in cross-compile environments, you can't use it and you have > to force the value otherwise you're screwed, and in local builds, you > simply don't need to specify them. For me, pcre-config --libs does not use `-L`. Dunno why this is the case for Apollon. For cross-compile, triplet-enabled pcre-config should be available (this is tested by autoconf) but on cross-compile toolchain that I see nowadays, the PATH is made such that you find pcre-config for crosscompilation before the one for the system. I don't know if a user is expected to rely on this. >> As for the ordering of -L, I would expect the user to specify `make >> LDFLAGS="-L/tmp/openssl/static"` and you rename the internal `LDFLAGS` >> to something else (instead of introducing another variable, LDFLAGS is >> the variable that a user can expect to override). $(LDFLAGS) will be >> used early (as currently done), so the specified directory will be first >> in the search path. > > That's interesting. In fact, the worst problem we have is that (except > for ADDINC/ADDLIB), the variables the user can specify already hold a > value and are overridden. That's how we added more and more variables, > so that you can specify extra build information without losing existing > ones. > > I've just checked, and all my build scripts already specify LDFLAGS, but > just for passing -g/-s/-static (basically what we can expect in LDFLAGS), > but none of them expects LDFLAGS to also override ARCH_FLAGS. So I think > it could already improve things if instead of having : > >LDFLAGS = $(ARCH_FLAGS) -g >... >$(LD) $(LDFLAGS) -o $@ $^ $(LDOPTS) > > we had : > >LDFLAGS = -g >... >$(LD) $(ARCH_FLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS) > > or even ideally : > >ARCH_LDFLAGS = $(ARCH_FLAGS) >LDFLAGS = -g >... >$(LD) $(ARCH_LDFLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS) > > I think we wouldn't break existing build scripts by such a small change > and would make it easier for packagers to force some paths without the > risk of overriding the arch-specific flags. Yes, this seems fine. -- Avoid multiple exits from loops. - The Elements of Programming Style (Kernighan & Plauger)
Re: Static haproxy/openssl build error
Hi Lukas,
On Sun, Sep 29, 2013 at 10:49:41PM +0200, Lukas Tribus wrote:
> Another thing regarding SSL_INC/SSL_LIB: when linking against static openssl,
> libdl is necessary. Previously I did this by appending ADDLIB with -ldl. It
> seems like doing the same in SSL_LIB doesn't work (for me), because -ldl must
> come after -lssl -lcrypto.
>
> Now, should we advise users and document to use something like this:
> SSL_INC=$STATICLIBSSL/include SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl
>
> Like previsouly suggested by Apollon, we could introduce a flag for
> statically linking openssl, like we have with PCRE (USE_STATIC_OPENSSL?).
>
> If we do that, we could also include -ldl automatically when using that USE
> flag.
>
> Thoughts?
I'm a bit hesitant here and am not completely fond of what we did for
PCRE_STATIC. The problem is that we force -Wl,-Bstatic then -Wl,-Bdynamic,
and that it breaks full static builds. There's no option in the linker
like "-Wl,-Bdefault" to say "let's come back to the default model", so
we have to force "dynamic" by hand at the end of inclusion of the lib
and complicate the things. For PCRE, the solution consists in using USE_PCRE
instead of USE_STATIC_PCRE when doing a full static build. But if for SSL
we automatically add -ldl, you quickly see the issue happen.
Or maybe we could have a variable "BUILD_MODEL" = {static,dynamic} that
we use to set the fallback mode and take the correct decisions when adding
libraries.
Anyway, I tend to prefer to let people pass an option to fix their build
issues than having a few other ones patch the makefile to get rid of
something that was added for laziness and breaks their build. Let's not
try to reproduce the autotools mess with a makefile :-)
Regards,
Willy
Re: Static haproxy/openssl build error
Hi Vincent, On Sun, Sep 29, 2013 at 10:27:30PM +0200, Vincent Bernat wrote: > ??? 29 septembre 2013 18:30 CEST, Willy Tarreau : > > > 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 > > I would use `pcre-config --libs` and `pcre-config --cflags` instead. The > user can still override this on make command line. > > PCRE_CFLAGS := $(shell pcre-config --cflags) > PCRE_LIBS := $(shell pcre-config --libs) But these would still cause the issue we're currently facing because they'll add -L/usr/lib or whatever is in the system path, so that does not fix the issue. Really I'd rather get rid of pcre-config completely. Anyway, in cross-compile environments, you can't use it and you have to force the value otherwise you're screwed, and in local builds, you simply don't need to specify them. > As for the ordering of -L, I would expect the user to specify `make > LDFLAGS="-L/tmp/openssl/static"` and you rename the internal `LDFLAGS` > to something else (instead of introducing another variable, LDFLAGS is > the variable that a user can expect to override). $(LDFLAGS) will be > used early (as currently done), so the specified directory will be first > in the search path. That's interesting. In fact, the worst problem we have is that (except for ADDINC/ADDLIB), the variables the user can specify already hold a value and are overridden. That's how we added more and more variables, so that you can specify extra build information without losing existing ones. I've just checked, and all my build scripts already specify LDFLAGS, but just for passing -g/-s/-static (basically what we can expect in LDFLAGS), but none of them expects LDFLAGS to also override ARCH_FLAGS. So I think it could already improve things if instead of having : LDFLAGS = $(ARCH_FLAGS) -g ... $(LD) $(LDFLAGS) -o $@ $^ $(LDOPTS) we had : LDFLAGS = -g ... $(LD) $(ARCH_FLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS) or even ideally : ARCH_LDFLAGS = $(ARCH_FLAGS) LDFLAGS = -g ... $(LD) $(ARCH_LDFLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS) I think we wouldn't break existing build scripts by such a small change and would make it easier for packagers to force some paths without the risk of overriding the arch-specific flags. Willy
Re: Static haproxy/openssl build error
❦ 29 septembre 2013 22:27 CEST, Vincent Bernat : > LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \ > $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ > $(AM_LDFLAGS) $(LDFLAGS) -o $@ > haproxy: ... > $(AM_V_CCLD)$(LINK) $(haproxy_OBJECTS) $(haproxy_LDADD) $(LIBS) > > So, the ordering would be as expected. I was unclear. What I mean is that the expectation of an autoconf build system (and therefore, the expectation of most users since it is the most widespread build system) is that the linker will use the following flags in the following order: - maintainer-specified CFLAGS (AM_CFLAGS) - user-specified CFLAGS (CFLAGS) The expectation for CFLAGS is that the user can override any flag set by AM_CFLAGS. - maintainer-specified LDFLAGS (AM_LDFLAGS) - user-specified LDFLAGS (LDFLAGS) Same thing as for CFLAGS. This holds because LDFLAGS should not contain either `-l` or `-L` options. It's for stuff like `-Wl,--as-needed`. Of course, for special cases, LDFLAGS can have any flag that is deemed necessary, like `-L/some/special/path` or `-lmyalternateallocator`. But not AM_LDFLAGS. - any object (OBJECTS) - object-specific libraries (LDADD/LIBADD) - project-specific libraries (LIBS) LDADD/LIBADD/LIBS are a combination of `-l`, `-L` or `.a`. No need to have three variables like here (there are 3 variables just because how stuff from automake are merged together). HAProxy's Makefile is almost "correct" with respect to those expectations. LDADD/LIBADD/LIBS is OPTIONS_LDFLAGS, AM_LDFLAGS is LDFLAGS + TARGET_LDFLAGS and you just need to rename LDFLAGS to HA_LDFLAGS and let the user specify LDFLAGS if she wants to. Same for CFLAGS. LDFLAGS default is usually empty. CFLAGS default is usually -O2 -g. Distributions will take advantage of this as well. In Debian, currently, we override CFLAGS and LDFLAGS (so, we don't get the optimisation stuff) to use our defaults because we want to use hardening flags (and I suppose we didn't notice that we were overriding some flags, like -fno-strict-aliasing). -- Write and test a big program in small pieces. - The Elements of Programming Style (Kernighan & Plauger)
RE: Static haproxy/openssl build error
Hi! >> 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. Confirmed. I did not see this because I either compiled without PCRE, or with all paths manually set, so pcre-config was not called. This patch fixes this, of course. Another thing regarding SSL_INC/SSL_LIB: when linking against static openssl, libdl is necessary. Previously I did this by appending ADDLIB with -ldl. It seems like doing the same in SSL_LIB doesn't work (for me), because -ldl must come after -lssl -lcrypto. Now, should we advise users and document to use something like this: SSL_INC=$STATICLIBSSL/include SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl Like previsouly suggested by Apollon, we could introduce a flag for statically linking openssl, like we have with PCRE (USE_STATIC_OPENSSL?). If we do that, we could also include -ldl automatically when using that USE flag. Thoughts? Regards, Lukas
Re: Static haproxy/openssl build error
❦ 29 septembre 2013 18:30 CEST, Willy Tarreau :
> 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
I would use `pcre-config --libs` and `pcre-config --cflags` instead. The
user can still override this on make command line.
PCRE_CFLAGS := $(shell pcre-config --cflags)
PCRE_LIBS := $(shell pcre-config --libs)
As for the ordering of -L, I would expect the user to specify `make
LDFLAGS="-L/tmp/openssl/static"` and you rename the internal `LDFLAGS`
to something else (instead of introducing another variable, LDFLAGS is
the variable that a user can expect to override). $(LDFLAGS) will be
used early (as currently done), so the specified directory will be first
in the search path.
This is similar to how it would work for an autoconf based build system:
haproxy_CFLAGS = @PCRE_FLAGS@
haproxy_LDADD = @PCRE_LDFLAGS@
automake will generate something like this:
LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
$(AM_LDFLAGS) $(LDFLAGS) -o $@
haproxy: ...
$(AM_V_CCLD)$(LINK) $(haproxy_OBJECTS) $(haproxy_LDADD) $(LIBS)
So, the ordering would be as expected.
--
printk("Entering UltraSMPenguin Mode...\n");
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c
Re: Static haproxy/openssl build error
Hi Willy,
On 18:30 Sun 29 Sep , Willy Tarreau wrote:
> 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.
Still, this approach does not properly work on most distributions
anymore. Debian and Ubuntu are shipping most of the libraries under
/usr/lib/-linux-gnu, but the libdir generated using ${prefix}/lib
is still /usr/lib. pcre-config can output the correct output path:
$ pcre-config --libs
-L/usr/lib/x86_64-linux-gnu -lpcre
but we would still end up inserting a system library path using -L.
> 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
>
Looks good to me, that's what we're essentially doing for the Debian
package right now anyway. Another approach would be to manually specify
the path to pcre-config (e.g. using a PCRE_CONFIG variable) if desired
and get `pcre-config --libs` and `pcre-config --cflags` from there if
specified. But pcre is a simple use-case, just specifying includes and
libdir should be enough.
Thanks,
Apollon
Re: Static haproxy/openssl build error
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
Re: Static haproxy/openssl build error
Hi Willy. It worked, thanks a lot. Output + build commands are below. On 2013-09-29 13:35, Willy Tarreau wrote: Hi Julien, On Fri, Sep 27, 2013 at 11:08:11AM +0200, Julien Vehent wrote: Hi everyone, I'm attempting to build HEAD with a statically compiled openssl, and get the following error: $ make TARGET=linux2628 USE_STATIC_PCRE=1 USE_OPENSSL=1 ADDINC=-I/tmp/staticlibssl/include ADDLIB="-L/tmp/staticlibssl/lib -ldl" [] gcc -g -o haproxy src/haproxy.o src/sessionhash.o src/base64.o src/protocol.o src/uri_auth.o src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o src/channel.o src/listener.o src/time.o src/fd.o src/pipe.o src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o src/frontend.o src/proxy.o src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o src/connection.o src/proto_http.o src/raw_sock.o src/appsession.o src/backend.o src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o src/stream_interface.o src/dumpstats.o src/proto_tcp.o src/session.o src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o src/memory.o src/freq_ctr.o src/auth.o src/compression.o src/payload.o src/ev_poll.o src/ev_epoll.o src/ssl_sock.o src/shctx.o ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o -lcrypt -lssl -lcrypto -L/usr/lib -Wl,-Bstatic -lpcreposix -lpcre -Wl,-Bdynamic -L/tmp/staticlibssl/lib -ldl src/ssl_sock.o: In function `smp_fetch_ssl_fc_npn': /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:2447: undefined reference to `SSL_get0_next_proto_negotiated' src/ssl_sock.o: In function `ssl_sock_prepare_srv_ctx': /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:959: undefined reference to `TLSv1_2_client_method' /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:955: undefined reference to `TLSv1_1_client_method' src/ssl_sock.o: In function `ssl_sock_prepare_ctx': /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:739: undefined reference to `SSL_CTX_set_next_protos_advertised_cb' /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:691: undefined reference to `TLSv1_2_server_method' /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:687: undefined reference to `TLSv1_1_server_method' collect2: ld returned 1 exit status make: *** [haproxy] Erreur 1 $ uname -r 2.6.32-bpo.4-amd64 OpenSSL was build with the commands below, and the produced openssl binary works fine. $ ./config --prefix=/tmp/staticlibssl/ no-shared enable-ec_nistp_64_gcc_128 $ make depend && make && make install_sw $ /tmp/staticlibssl/bin/openssl version OpenSSL 1.1.0-dev xx XXX Any idea what could be missing here? Is the system openssl lib conflicting with the statically compiled one? 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 : # in the usual path, use SSL_INC=/path/to/inc and SSL_LIB=/path/to/lib. BUILD_OPTIONS += $(call ignore_implicit,USE_OPENSSL) OPTIONS_CFLAGS += -DUSE_OPENSSL $(if $(SSL_INC),-I$(SSL_INC)) OPTIONS_LDFLAGS += $(if $(SSL_LIB),-L$(SSL_LIB)) -lssl -lcrypto If you have a recent enough haproxy snapshot, simply make these two variables point to the proper location and it will be OK. Best regards, Willy --- Build script - #!/usr/bin/env bash export STATICLIBSSL="/tmp/staticlibssl" #-- Build static openssl cd openssl-1.0.1e rm -rf "$STATICLIBSSL" mkdir "$STATICLIBSSL" make clean ./config --prefix=$STATICLIBSSL no-shared enable-ec_nistp_64_gcc_128 make depend make make install_sw #-- Build static haproxy cd haproxy git pull make clean make TARGET=linux2628 USE_STATIC_PCRE=1 USE_OPENSSL=1 SSL_INC=$STATICLIBSSL/include SSL_LIB="$STATICLIBSSL/lib -ldl" --- Compiled bin - $ ./haproxy -vv HA-Proxy version 1.5-dev19-68 2013/09/23 Copyright 2000-2013 Willy Tarreau Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = -O2 -g -fno-strict-aliasing OPTIONS = USE_OPENSSL=1 USE_STATIC_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built without zlib support (USE_ZLIB not set) Compression algorithms supported : identity Built with OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 Running on OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library suppo
Re: Static haproxy/openssl build error
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
Re: Static haproxy/openssl build error
Hi Lukas, On Sun, Sep 29, 2013 at 02:41:11PM +0200, Lukas Tribus wrote: > Hi! > > (sorry for duplicates, previous mail hit the wire to fast...) hehe :-) > > 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. > > Ok, but what I don't get is why does it work on some system and not on others? > > For me, on Debian and Ubuntu, it always worked fine, see this: > > dynamically linked against system lib on debian squezze: > $ ./haproxy -vv | grep "OpenSSL version" > Built with OpenSSL version : OpenSSL 0.9.8o 01 Jun 2010 > Running on OpenSSL version : OpenSSL 0.9.8o 01 Jun 2010 > $ ldd haproxy > linux-gate.so.1 => (0xb77c7000) > libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb778f000) > libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7743000) > libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 > (0xb75ea000) > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74a3000) > libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749f000) > libz.so.1 => /usr/lib/libz.so.1 (0xb748b000) > /lib/ld-linux.so.2 (0xb77c8000) > $ > > linked to static lib on debian squezze with ADDINC/ADDLIB: > $ ./haproxy -vv | grep "OpenSSL version" > Built with OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 > Running on OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 > $ ldd haproxy > linux-gate.so.1 => (0xb77c2000) > libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb778a000) > libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7786000) > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb763e000) > /lib/ld-linux.so.2 (0xb77c3000) > $ > > > compiling/linking on the latter looked like this: > [...] > ebtree/ebistree.o -lcrypt -lssl -lcrypto -L/home/lukas/libsslbuild/lib > -ldl > [...] > src/haproxy-systemd-wrapper.o -lcrypt -lssl -lcrypto > -L/home/lukas/libsslbuild/lib -ldl > > > ... and yet it compiles fine. I must say that I have no idea in fact. It could depend on so many things! The linker tends to be smart for us and make things work when we'd rather have them fail, the worst thing in my opinion being that it automatically picks .so when both .so and .a are found :-/ > > 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've seen this in git, yes. We need to update README, I will sent a patch > about that. Great. I remember not updating it after looking for PCRE_INC there and seeing it was not referenced. Wrong search. I should have checked ADDINC which was the previous way of doing it! Thanks! willy
RE: Static haproxy/openssl build error
Hi! (sorry for duplicates, previous mail hit the wire to fast...) > 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. Ok, but what I don't get is why does it work on some system and not on others? For me, on Debian and Ubuntu, it always worked fine, see this: dynamically linked against system lib on debian squezze: $ ./haproxy -vv | grep "OpenSSL version" Built with OpenSSL version : OpenSSL 0.9.8o 01 Jun 2010 Running on OpenSSL version : OpenSSL 0.9.8o 01 Jun 2010 $ ldd haproxy linux-gate.so.1 => (0xb77c7000) libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb778f000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7743000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb75ea000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74a3000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749f000) libz.so.1 => /usr/lib/libz.so.1 (0xb748b000) /lib/ld-linux.so.2 (0xb77c8000) $ linked to static lib on debian squezze with ADDINC/ADDLIB: $ ./haproxy -vv | grep "OpenSSL version" Built with OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 Running on OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 $ ldd haproxy linux-gate.so.1 => (0xb77c2000) libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb778a000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7786000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb763e000) /lib/ld-linux.so.2 (0xb77c3000) $ compiling/linking on the latter looked like this: [...] ebtree/ebistree.o -lcrypt -lssl -lcrypto -L/home/lukas/libsslbuild/lib -ldl [...] src/haproxy-systemd-wrapper.o -lcrypt -lssl -lcrypto -L/home/lukas/libsslbuild/lib -ldl ... and yet it compiles fine. > 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've seen this in git, yes. We need to update README, I will sent a patch about that. Regards, Lukas
RE: Static haproxy/openssl build error
Hi! > 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. Ok, but what I don't get is why does it work on some system and not on others? For me, on Debian and Ubuntu, it always worked fine, see this: > 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 : > > # in the usual path, use SSL_INC=/path/to/inc and SSL_LIB=/path/to/lib. > BUILD_OPTIONS += $(call ignore_implicit,USE_OPENSSL) > OPTIONS_CFLAGS += -DUSE_OPENSSL $(if $(SSL_INC),-I$(SSL_INC)) > OPTIONS_LDFLAGS += $(if $(SSL_LIB),-L$(SSL_LIB)) -lssl -lcrypto > > If you have a recent enough haproxy snapshot, simply make these two > variables point to the proper location and it will be OK. > > Best regards, > Willy > >
Re: Static haproxy/openssl build error
Hi Julien, On Fri, Sep 27, 2013 at 11:08:11AM +0200, Julien Vehent wrote: > Hi everyone, > > I'm attempting to build HEAD with a statically compiled openssl, and get > the following error: > > $ make TARGET=linux2628 USE_STATIC_PCRE=1 USE_OPENSSL=1 > ADDINC=-I/tmp/staticlibssl/include ADDLIB="-L/tmp/staticlibssl/lib -ldl" > [] > gcc -g -o haproxy src/haproxy.o src/sessionhash.o src/base64.o > src/protocol.o src/uri_auth.o src/standard.o src/buffer.o src/log.o > src/task.o src/chunk.o src/channel.o src/listener.o src/time.o src/fd.o > src/pipe.o src/regex.o src/cfgparse.o src/server.o src/checks.o > src/queue.o src/frontend.o src/proxy.o src/peers.o src/arg.o > src/stick_table.o src/proto_uxst.o src/connection.o src/proto_http.o > src/raw_sock.o src/appsession.o src/backend.o src/lb_chash.o > src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o > src/stream_interface.o src/dumpstats.o src/proto_tcp.o src/session.o > src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o > src/memory.o src/freq_ctr.o src/auth.o src/compression.o src/payload.o > src/ev_poll.o src/ev_epoll.o src/ssl_sock.o src/shctx.o ebtree/ebtree.o > ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o > ebtree/ebimtree.o ebtree/ebistree.o -lcrypt -lssl -lcrypto -L/usr/lib > -Wl,-Bstatic -lpcreposix -lpcre -Wl,-Bdynamic -L/tmp/staticlibssl/lib -ldl > src/ssl_sock.o: In function `smp_fetch_ssl_fc_npn': > /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:2447: undefined > reference to `SSL_get0_next_proto_negotiated' > src/ssl_sock.o: In function `ssl_sock_prepare_srv_ctx': > /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:959: undefined > reference to `TLSv1_2_client_method' > /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:955: undefined > reference to `TLSv1_1_client_method' > src/ssl_sock.o: In function `ssl_sock_prepare_ctx': > /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:739: undefined > reference to `SSL_CTX_set_next_protos_advertised_cb' > /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:691: undefined > reference to `TLSv1_2_server_method' > /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:687: undefined > reference to `TLSv1_1_server_method' > collect2: ld returned 1 exit status > make: *** [haproxy] Erreur 1 > > $ uname -r > 2.6.32-bpo.4-amd64 > > OpenSSL was build with the commands below, and the produced openssl > binary works fine. > > $ ./config --prefix=/tmp/staticlibssl/ no-shared > enable-ec_nistp_64_gcc_128 > $ make depend && make && make install_sw > $ /tmp/staticlibssl/bin/openssl version > OpenSSL 1.1.0-dev xx XXX > > Any idea what could be missing here? Is the system openssl lib > conflicting with the statically compiled one? 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 : # in the usual path, use SSL_INC=/path/to/inc and SSL_LIB=/path/to/lib. BUILD_OPTIONS += $(call ignore_implicit,USE_OPENSSL) OPTIONS_CFLAGS += -DUSE_OPENSSL $(if $(SSL_INC),-I$(SSL_INC)) OPTIONS_LDFLAGS += $(if $(SSL_LIB),-L$(SSL_LIB)) -lssl -lcrypto If you have a recent enough haproxy snapshot, simply make these two variables point to the proper location and it will be OK. Best regards, Willy
RE: Static haproxy/openssl build error
Hi Apollon, hi Julien, > HAProxy's build system does not currently support static linking > against openssl. Well the linker should detect that you are pointing the path of a static-only build of openssl and link it accordingly (no libcrypto.so there, just a static libcrypto.a file). > I bet if you do an ldd against the generated haproxy binary it will be > dynamically linked against the system's OpenSSL, not statically against > your own version. When I compile it this way under my Ubuntu system, I see it has been statically linked to haproxy: $ ./haproxy -vv | grep "OpenSSL version" Built with OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 Running on OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 $ ldd haproxy linux-gate.so.1 => (0xb7716000) libcrypt.so.1 => /lib/i386-linux-gnu/libcrypt.so.1 (0xb76dd000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb76c7000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb76c1000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7518000) /lib/ld-linux.so.2 (0xb7717000) $ (note that libcrypt is not libcrypto). This is how it looks like when its build dynamically against the system library: $ ./haproxy -vv | grep "OpenSSL version" Built with OpenSSL version : OpenSSL 1.0.1 14 Mar 2012 Running on OpenSSL version : OpenSSL 1.0.1 14 Mar 2012 $ ldd haproxy linux-gate.so.1 => (0xb76ef000) libcrypt.so.1 => /lib/i386-linux-gnu/libcrypt.so.1 (0xb76b6000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb76a) libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xb7648000) libcrypto.so.1.0.0 => /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xb749d000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb72f4000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb72ef000) /lib/ld-linux.so.2 (0xb76f) $ That being said, the error messages does suggest that something is not right with the openssl linking or path. Can you triple check that you compiled openssl with the no-shared keyword and that the paths are perfectly correct? Also, please post the full compile log of openssl 1.0.1e and haproxy itself somewhere, so we can see the full picture. > $ ./config --prefix=/tmp/staticlibssl/ no-shared enable-ec_nistp_64_gcc_128 > $ make depend && make && make install_sw You shouldn't need "make depend". Does the configure script tell you to do that? enable-ec_nistp_64_gcc_128 is only available on amd64, if you enable it on a different platform, openssl may not compile fully. FYI: here is a build on debian squezze (i386) with a static openssl build: $ cat /etc/issue.net Debian GNU/Linux 6.0 $ ./haproxy -vv | grep "OpenSSL version" Built with OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 Running on OpenSSL version : OpenSSL 1.0.1e 11 Feb 2013 $ ldd haproxy linux-gate.so.1 => (0xb77b5000) libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb777d000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7779000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7631000) /lib/ld-linux.so.2 (0xb77b6000) $ > The following patch should do it (although it should really introduce a > new flag): A build flag to do this would certainly come in handy. Would you be willing to write a patch for that? > PS: personally I wouldn't link statically against OpenSSL. I'd just > co-install libssl1.0.0 along with the system's libssl0.9.8. If you have a whole farm of load-balancers, a single executable with both PCRE and SSL statically linked to it is easier and faster to deploy. Thats what I like with that method. Of course, if you need to update openssl or PCRE for some reason, you need a new executable. But you would need to restart haproxy anyway to pick up the new lib. Regards, Lukas
Re: Static haproxy/openssl build error
Hi Julien, On 10:35 Sat 28 Sep , Julien Vehent wrote: > On 2013-09-27 21:17, Lukas Tribus wrote: > >Try stable OpenSSL 1.0.1e, that should work. > > I did, and I get the exact same error. > The problem happens on Debian Squeeze. My laptop on Fedora 19 > doesn't have the issue. > HAProxy's build system does not currently support static linking against openssl. The reason it works on Fedora 19, is probably because the system already ships OpenSSL 1.0.1 in the system library path; I bet if you do an ldd against the generated haproxy binary it will be dynamically linked against the system's OpenSSL, not statically against your own version. The only way to statically link against OpenSSL would be to patch HAProxy's Makefile to do more or less what is done with static PCRE: pass -Wl,-Bstatic before -lssl and -Wl,-Bdynamic afterwards. The following patch should do it (although it should really introduce a new flag): diff --git a/Makefile b/Makefile index 5e12af8..fc4d1bc 100644 --- a/Makefile +++ b/Makefile @@ -521,7 +521,7 @@ ifneq ($(USE_OPENSSL),) # to specify -I and -L if your OpenSSL library is not in the standard path. BUILD_OPTIONS += $(call ignore_implicit,USE_OPENSSL) OPTIONS_CFLAGS += -DUSE_OPENSSL -OPTIONS_LDFLAGS += -lssl -lcrypto +OPTIONS_LDFLAGS += -Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic OPTIONS_OBJS += src/ssl_sock.o src/shctx.o ifneq ($(USE_PRIVATE_CACHE),) OPTIONS_CFLAGS += -DUSE_PRIVATE_CACHE -- Regards, Apollon PS: personally I wouldn't link statically against OpenSSL. I'd just co-install libssl1.0.0 along with the system's libssl0.9.8.
RE: Static haproxy/openssl build error
On 2013-09-27 21:17, Lukas Tribus wrote: Hi Julien, I'm attempting to build HEAD with a statically compiled openssl, and get the following error: [...] $ /tmp/staticlibssl/bin/openssl version OpenSSL 1.1.0-dev xx XXX Any idea what could be missing here? Try stable OpenSSL 1.0.1e, that should work. I did, and I get the exact same error. The problem happens on Debian Squeeze. My laptop on Fedora 19 doesn't have the issue. - Julien
RE: Static haproxy/openssl build error
Hi Julien, > I'm attempting to build HEAD with a statically compiled openssl, and get > the following error: > [...] > $ /tmp/staticlibssl/bin/openssl version > OpenSSL 1.1.0-dev xx XXX > > Any idea what could be missing here? Try stable OpenSSL 1.0.1e, that should work. Regards, Lukas
Static haproxy/openssl build error
Hi everyone, I'm attempting to build HEAD with a statically compiled openssl, and get the following error: $ make TARGET=linux2628 USE_STATIC_PCRE=1 USE_OPENSSL=1 ADDINC=-I/tmp/staticlibssl/include ADDLIB="-L/tmp/staticlibssl/lib -ldl" [] gcc -g -o haproxy src/haproxy.o src/sessionhash.o src/base64.o src/protocol.o src/uri_auth.o src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o src/channel.o src/listener.o src/time.o src/fd.o src/pipe.o src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o src/frontend.o src/proxy.o src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o src/connection.o src/proto_http.o src/raw_sock.o src/appsession.o src/backend.o src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o src/stream_interface.o src/dumpstats.o src/proto_tcp.o src/session.o src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o src/memory.o src/freq_ctr.o src/auth.o src/compression.o src/payload.o src/ev_poll.o src/ev_epoll.o src/ssl_sock.o src/shctx.o ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o -lcrypt -lssl -lcrypto -L/usr/lib -Wl,-Bstatic -lpcreposix -lpcre -Wl,-Bdynamic -L/tmp/staticlibssl/lib -ldl src/ssl_sock.o: In function `smp_fetch_ssl_fc_npn': /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:2447: undefined reference to `SSL_get0_next_proto_negotiated' src/ssl_sock.o: In function `ssl_sock_prepare_srv_ctx': /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:959: undefined reference to `TLSv1_2_client_method' /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:955: undefined reference to `TLSv1_1_client_method' src/ssl_sock.o: In function `ssl_sock_prepare_ctx': /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:739: undefined reference to `SSL_CTX_set_next_protos_advertised_cb' /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:691: undefined reference to `TLSv1_2_server_method' /home/julien/haproxy_openssl/haproxy/src/ssl_sock.c:687: undefined reference to `TLSv1_1_server_method' collect2: ld returned 1 exit status make: *** [haproxy] Erreur 1 $ uname -r 2.6.32-bpo.4-amd64 OpenSSL was build with the commands below, and the produced openssl binary works fine. $ ./config --prefix=/tmp/staticlibssl/ no-shared enable-ec_nistp_64_gcc_128 $ make depend && make && make install_sw $ /tmp/staticlibssl/bin/openssl version OpenSSL 1.1.0-dev xx XXX Any idea what could be missing here? Is the system openssl lib conflicting with the statically compiled one? -- Julien Vehent http://jve.linuxwall.info
