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 (0xb76a0000) 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 (0xb76f0000) $ 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
