1.7.0 beta & rc1: libcurl errors

Joshua Root jmr at macports.org
Mon Dec 8 15:04:03 PST 2008


Bryan Blackburn wrote:
> On Mon, Dec 08, 2008 at 04:19:41PM -0600, Ryan Schmidt said:
>> On Dec 8, 2008, at 15:41, Bryan Blackburn wrote:
>>
>>> On Mon, Dec 08, 2008 at 03:25:19PM -0500, Jay Levitt said:
>>>
>>>> I tried to rebuild the port, but the port command had the same  
>>>> problem:
>>>>
>>>> sudo port clean git
>>>> couldn't load file
>>>> "/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib":
>>>> dlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10):
>>>> Library not loaded: /opt/local/lib/libcurl.4.dylib
>>>>   Referenced from: /opt/local/share/macports/Tcl/pextlib1.0/ 
>>>> Pextlib.dylib
>>>>   Reason: Incompatible library version: Pextlib.dylib requires  
>>>> version
>>>> 6.0.0 or later, but libcurl.4.dylib provides version 5.0.0
>>> This could be an issue with selfupdate as it should be linking Pextlib
>>> against the system libcurl, not one found in MacPorts.  Will have to 
>>> look
>>> into this.
>> I remember when building MacPorts manually, it will link with its own  
>> ports, which isn't so great IMHO. Which is why I now build MacPorts  
>> through a script which first sets the PATH so it doesn't contain the  
>> MacPorts prefix. Like this:
> 
> FYI I've never had MacPorts link against anything installed by MacPorts when
> using configure/make/make install.  I do have the curl port installed by
> Pextlib is still linked to the system libcurl...

Could the wrong libcurl be picked up if there is something like
LDFLAGS=-L/opt/local/lib in the environment? If that's what happened to
Jay, it shouldn't be a problem with selfupdate because the environment
is sanitised.

- Josh


More information about the macports-users mailing list