[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jochen Roderburg
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/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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]