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/ssl
with 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.
Regards, J.Roderburg
