|Subject:||Re: [Bug-wget] Wget 1.16.1 detection of non-system openssl broken on MacOSX.|
|Date:||Sun, 14 Dec 2014 18:12:05 +0000|
|User-agent:||Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0|
OK, that worked, thanks; indeed, all I had to do was 'PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig ./configure blah blah'. Easy enough. (That's the default location for a built-from-source openssl; is openssl not putting its .pc file where it should?)I guess yes, if you 'make install' your local copy of OpenSSL.But that's only half the battle, because that only covers the case where the Mac user has pkg-config installed. Pkg-config doesn't come with OSX or the Apple dev tools. Up through wget 1.16, the pkgconfigless Mac user could rely on --with-libssl-prefix to point wget to the right place.Please see the output of ./configure --help. If you don't have pkg-config installed, please try the following Add "-I/usr/local/ssl/include" to your CFLAGS and add "-L/usr/local/ssl/lib" to your LDFLAGS. export both and ./configure.
I have seen now here several work-arounds like the above for this issue, but no real answer to the OP's question: Why does a ./configure --with-ssl=openssl --with-libssl-prefix=/usr/local/sslwith wget 1.16.1 no longer give the same results as earlier versions in the situation on his system. From the discussion I understand that his situation is: the unwanted library installation is found by pkg-config and the wanted installation is not.
In the current configure script I see that the --with-libssl-prefix option (and probably also all the other --with-xxxxxx-prefix options) is only handled by the old library detection code and not by the new pkg-config based detection. So when a library is found by pkg-config it cannot be overrun any longer by these configure options.
I think the clean and compatible way to handle this issue would be to change the sequence of these three ways to find a library to: first respect the --with-xxxxxx-prefix option, then use the pkg-config method and finally the old detection code. Maybe one could also have a look how other projects handle this which offer similar options.
|[Prev in Thread]||Current Thread||[Next in Thread]|