Re: Static haproxy/openssl build error

[Willy Tarreau]

Hi Vincent,

On Sun, Sep 29, 2013 at 10:27:30PM +0200, Vincent Bernat wrote:
  ??? 29 septembre 2013 18:30 CEST, Willy Tarreau w...@1wt.eu :
 
  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

[Willy Tarreau]

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

[Vincent Bernat]

 ❦ 30 septembre 2013 11:30 CEST, Willy Tarreau w...@1wt.eu :

 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

[Apollon Oikonomopoulos]

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

[Apollon Oikonomopoulos]

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

[Vincent Bernat]

 ❦ 30 septembre 2013 13:01 CEST, Apollon Oikonomopoulos apoi...@gmail.com :

 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

[Lukas Tribus]

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

[Lukas Tribus]

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

[Willy Tarreau]

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

[Lukas Tribus]

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

[Lukas Tribus]

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

[Willy Tarreau]

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

[Apollon Oikonomopoulos]

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

[Julien Vehent]

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 w...@1wt.eu

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 supports 

Re: Static haproxy/openssl build error

[Willy Tarreau]

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

[Apollon Oikonomopoulos]

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/arch-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

[Vincent Bernat]

 ❦ 29 septembre 2013 18:30 CEST, Willy Tarreau w...@1wt.eu :

 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

[Lukas Tribus]

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

[Vincent Bernat]

 ❦ 29 septembre 2013 22:27 CEST, Vincent Bernat ber...@luffy.cx :

 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

[Julien Vehent]

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

[Apollon Oikonomopoulos]

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

[Lukas Tribus]

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