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