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 _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users