On Sat, 16 Nov 2013 17:16:00 +0100
Rainer Jung <rainer.j...@kippdata.de> wrote:
>
> Summary
> =======
> [...]
> - crypto configure for OpenSSL expected to fail at least on Solaris,
> because when linking against the libssl we need
> the additional flags "-ldl -lsocket -lnsl". Currently
> there's no way to fix this apart from hacking configure.
> For Linux I'm not sure, but likely you'll need "-ldl".
That is a bug in openssl provided that the correct pkg-config hacks
were added (these are well documented in httpd's mod_ssl configure).
What does pkg-config report? My linux flavor;
$ pkg-config --libs-only-L --libs-only-other --libs-only-l openssl
-lssl -lcrypto
It was supposed be the complete guide to linking to openssl. -ldl
on linux was obviously missing, but actually unnecessary (the system
run time link loader does this work for us when dependent libraries
are correctly linked to the target library).
If libssl.so.n.n.n and libcrypto.so.n.n.n need these, *those libs*
should already contain those dependencies. If that isn't possible
(e.g. static libcrypto.a and libssl.a), then the pkg-config output
should reflect the correct bindings. E.g. again on my linux...
$ldd /usr/lib64/libssl.so
linux-vdso.so.1 => (0x00007fff569fe000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2
(0x00007fdf1b321000) libkrb5.so.3 => /lib64/libkrb5.so.3
(0x00007fdf1b042000) libcom_err.so.2 => /lib64/libcom_err.so.2
(0x00007fdf1ae3e000) libk5crypto.so.3 => /lib64/libk5crypto.so.3
(0x00007fdf1ac09000) libcrypto.so.10 => /lib64/libcrypto.so.10
(0x00007fdf1a829000) libdl.so.2 => /lib64/libdl.so.2
(0x00007fdf1a625000) libz.so.1 => /lib64/libz.so.1 (0x00007fdf1a40f000)
libc.so.6 => /lib64/libc.so.6 (0x00007fdf1a04d000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0
(0x00007fdf19e3f000) libkeyutils.so.1 => /lib64/libkeyutils.so.1
(0x00007fdf19c3b000) libresolv.so.2 => /lib64/libresolv.so.2
(0x00007fdf19a20000) libpthread.so.0 => /lib64/libpthread.so.0
(0x00007fdf19804000) /lib64/ld-linux-x86-64.so.2 (0x00007fdf1b81a000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fdf195e0000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fdf1937c000)
So there is no need for -ldl to be defined by my app to link to -lssl.
And were I to link libssl.a static, then pkg-config addresses these issues;
$ pkg-config --static --libs-only-L --libs-only-other --libs-only-l openssl
-lssl -lcrypto -ldl -lz -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto
(I'm getting frustrated with libapr trying to compensate for all the
broken build/installations out there, w.t.h. are those maintainers?)
> - LDADD flags are typically not respected during configure,
> only during the make.
By design, these weren't intended to be external inputs, so not really
surprised. Overridden during make at the user's peril :) It sounds
like a possible enhancement, however.
> - configure fails for Berkeley DB in non-standard path,
> because it doesn't add an rpath to conftest and then tries
> to run the compiled conftest binary.
Well, we roll our own detection, so I'm not shocked. AFAICT a default
db-devel (4 or 5) on linux installs neither pkg-config hints nor any
db-config style interrogation script. Is there some hinting for db4/5
that I'm missing?
> - no rpath for ldap, mysql and crypto dso extensions. So no
> way to run the result without LD_LIBRARY_PATH.
> Interesting: the m4 file does add an rpath only for oracle.
> Since there's no platform independent way to add rpath,
> we might want to remove it everywhere (and users would need
> to use the respective LDADD variables).
This all seems to tie into the same point, each with it's own rules and
usage pattern. e.g.
$ mysql_config --libs
-L/usr/lib64/mysql -lmysqlclient -lpthread -lz -lm -lssl -lcrypto -ldl
(and lo, there's the -ldl you were worried about :)
I don't think dropping rpath entirely is a good idea. For cases where
we are adding rpath's - perhaps a link flag override? In fact, I'd
expect the combination of libtool and configure to already hint that
for us.
> - Windows Build system:
> - test/testutildll.dsp and test/testutillib.dsp are the only DSP
> files containing "Release9x" and "Debug9x" configuration info.
> IMHO that's obsolete and could be removed.
> Probably also in Makefile.win?
Yup, those should die. I'll make it so right now.
