Am Sonntag, 14. Dezember 2014, 18:12:05 schrieb Jochen Roderburg: > >>> 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.
Thanks for the sum up, Jochen. I already spent some time to find a project that handles such cases, unlucky so far. I often could see the use of pkg-config without a fallback. The docs say: install pkg-config or die. That is also an option for us, especially since pkg-config becomes standard more and more. But of course, If we find an example how to implement that *- prefix stuff in a proper and maintainable manner (easy to read and understand) in configure.ac, that is the way to go. I appreciate any help in finding an example. Else we have to amend the documentation... I already made up a patch for the docs, but I am willing to wait a while before I push it. Regards, Tim
signature.asc
Description: This is a digitally signed message part.
