Agreed. Seems we aren't correctly digging into pkgconfig or similar.
On Nov 15, 2017 6:12 PM, "Rainer Jung" <rainer.j...@kippdata.de> wrote: 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
