Am 15.11.2017 um 22:02 schrieb Helmut K. C. Tessarek:
On 2017-11-15 03:53, Rainer Jung wrote:
Could you please provide the config.log that you get from that variant?
We should be able from that to see where and why configure fails.

I have attached both config.log files in my first original post:

./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr
--with-crypto --with-openssl=/usr/local/ssl

is in config.log.1

./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr
--with-crypto --with-openssl=/usr/local/ssl/lib

is in config.log.2

I'd say it is a bug in our configure script. Your OpenSSL crypto lib has a dependency on the "dl" library (dynamical loading) which is normal. When configure tries to compile a test program to detect whether OpenSSL support EVP_CIPHER_CTX_new, linking that program fails because of undefined symbols which would be available in the "dl" library:

/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
dso_dlfcn.c:(.text+0x11): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x24): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x2f): undefined reference to `dlclose'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
dso_dlfcn.c:(.text+0x354): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x412): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
dso_dlfcn.c:(.text+0x484): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x542): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
dso_dlfcn.c:(.text+0x5a9): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x60d): undefined reference to `dlclose'
dso_dlfcn.c:(.text+0x645): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
dso_dlfcn.c:(.text+0x6d1): undefined reference to `dladdr'
dso_dlfcn.c:(.text+0x731): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
dso_dlfcn.c:(.text+0x792): undefined reference to `dlclose'
collect2: error: ld returned 1 exit status

IMHO there is no clean and easy workaround but for now it should be acceptable to set your LIBS environment variable to "-ldl" before running configure. Please don' give up if this still fails, it can well be that we see other OpenSSL check failures for other reasons later during configure. Simply provide the config.log again and I will have another look.

During build time there is a clean way of supplying additional OpenSSL dependencies and flags like "-L..." and "-R..." or "-Wl,-rpath,..." namely by providing them in the environment variable LDADD_crypto_openssl. But this variable is not used during configure time.

Some platforms like Solaris need additional dependency libs, namely "-lsocket -lnsl". Some builds of OpenSSL depend on "-lz" for compresion, but for safety reasons more modern builds should have compression support turned of in OpenSSL.

On your second run, when using the "wrong" path to OpenSSL, the above test (for example) ends up doing

configure:4952: checking for EVP_CIPHER_CTX_new in -lcrypto
configure:4977: gcc -o conftest -g -O2 -pthread -DLINUX -D_REENTRANT -D_GNU_SOURCE -I/usr/local/ssl/lib/include -L/usr/local/ssl/lib/lib conftest.c -lcrypto >&5
configure:4977: $? = 0

but since there is not OpenSSL crypto library at /usr/local/ssl/lib/lib the program will simply be linked with the platform OpenSSL library and that one seems to not have the "dl" dependency.

On Linux you can use "objdump" to look at dependencies of libraries, so for instance

objdump /usr/local/lib/libcrypto.so

should show you an extry "NEEDED" for libdl.so.SOMEVERSION

Running the same command for your platform libcrypto.so, that will likely not be there. There's nothing wrong with your private OpenSSL copy, it just explains why the second configure run showed the differing behavior.

As a real fix IMHO we need to add PKG_CONFIG checks to our OpenSSL handling in configure, so that we learn from the pc file the OpenSSL dependencies. Such code is already present for the nss crypto handling in the same configure and is missing from the OpenSSL part.

Regards,

Rainer

Reply via email to