Re: [Bug-wget] Wget 1.16.1 detection of non-system openssl broken on MacOSX.

[Tim Ruehsen]

Hi Jochen,

On Thursday 18 December 2014 16:06:01 Jochen Roderburg wrote:
> Hi Tim,
> 
> Am 16.12.2014 um 14:00 schrieb Tim Ruehsen:
> > That is not so easy, since when having
> > --with-libssl-prefix=/usr/local/ssl,
> > you can't just
> > OPENSSL_CFLAGS=$with_libssl_prefix/include
> > OPENSSL_LIBS=$with_libssl_prefix/lib
> > You also have to manually specify the libraries you want to link with...
> > this can be different on different systems.
> 
> You are right, and this does also not ensure that the wanted libraries
> are actually used at run-time, on Linux e.g. the OPENSSL_LIBS must also
> somehow be in the dynamic library load path.
> 
> > So I decided to set PKG_CONFIG_PATH before the check and unset it
> > afterwards. It works for me... but I failed to test it without
> > pkg-config. Without pkg- config I couldn't get autoreconf working :-(
> 
> Unfortunately this approach has the same problems as it also does not do
> more than set the inlcude and lib paths.
> 
> 
> I made the following experiments on my Linux:
> 
> Installed a current OPENSSL from source in /usr/local/openssl (with
> openssl configure:  ./config --prefix=/usr/local/openssl shared)
> 
> Configured and built wget 1.16.1 with your PKG_CONFIG_PATH patch (with
> wget configure: configure --with-ssl=openssl
> --with-libssl-prefix=/usr/local/openssl).
> 
> With an active pkg-config program I see now the following in the config
> summary:
> CFlags:  -I/usr/include/uuid   -I/usr/local/openssl/include
> -DHAVE_LIBSSL   -DNDEBUG
> Libs:    -lpcre   -luuid   -L/usr/local/openssl/lib -lssl -lcrypto -lz
>    -lidn
> 
> So the compile and link phase will use the wanted files, but a ldd on
> the resulting wget binary still shows:
> 
>          libssl.so.1.0.0 => /lib/libssl.so.1.0.0
>          libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0
> 
> With a deactivated pkg-config program the old library detection code
> seems to be used and I get:
> 
> CFlags:   -DNDEBUG -I/usr/local/openssl/include
> Libs:     /usr/local/openssl/lib/libssl.so
> /usr/local/openssl/lib/libcrypto.so
>            Wl,-rpath -Wl,/usr/local/openssl/lib/ -ldl -lz  -lidn -luuid
> -lpcre
> 
> and ldd shows now:
> 
>          libssl.so.1.0.0 => /usr/local/openssl/lib/libssl.so.1.0.0
>          libcrypto.so.1.0.0 => /usr/local/openssl/lib/libcrypto.so.1.0.0
> 
> The wanted openssl libraries are inserted here with full path names and
> really used.

Full ACK. I made the same experiences yesterday evening working on a different 
projekt. There are some more side-effects introduced by pkg-config. Very, very 
ugly. And this is (of course) not limited to OpenSSL.

> Therefore I see now only one possibility to keep these two prefix
> options without more problems and new questions, namely skip the
> pkg-config based completely for the SSL libraries if these options are
> used.

Having a wild mixture of libraries and library versions requires, as you say, 
full library path names for the linker. Especially when these libraries have a 
common lib directory (like /usr/local/lib) and/or include directory. At least 
-L won't easily work (same with -I).

I like your idea of skipping pkg-config in case of these options given, simple 
and clever ! 

Tim

signature.asc
Description: This is a digitally signed message part.