bug-wget
[Top][All Lists]
Advanced

[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: Tim Rühsen
Subject: Re: [Bug-wget] Wget 1.16.1 detection of non-system openssl broken on MacOSX.
Date: Sun, 14 Dec 2014 18:30 +0100
User-agent: KMail/4.14.2 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )

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

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


reply via email to

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