MacPorts 1.5.2 now available

[Jason Stelzer]

On Aug 21, 2007, at 8:00 PM, Bryan Blackburn wrote:

> On Aug 21, 2007, at 3:33 PM, Ryan Schmidt wrote:
> ...
>>
>> Devs: I think this problem occurs because MacPorts needs a newer  
>> version of readline than the one you have in /usr/local. Couldn't  
>> we add a check to ./configure to make sure the correct version of  
>> readline is available, and issue a sensible error message if not,  
>> rather than failing with this unfortunate undefined symbols error  
>> later on? Or, couldn't we instruct configure never to look for  
>> anything in /usr/local? I believe the latter has been suggested  
>> before but I don't remember the outcome.
>>
>
> The last time I looked into something like this, it was my  
> conclusion that /usr/local is considered special by gcc and hence,  
> you can't remove it from the list.  It would definitely be a great  
> thing if this has changed, or I was wrong, because having MP tell  
> gcc to always ignore /usr/local would definitely solve many  
> problems, the recurring readline issue being one of the most common  
> of course.

Its not that /usr/local is special, its that it is part of the  
standard runtime/compile time search path by default. You should be  
able to override its search vial -L at compile time and  
DYLD_LIBRARY_PATH at runtime.

Shared libraries on os x work almost exactly like they do on linux.  
Either way if you want multiple, distinct duplicates of shared  
libraries it is completely possible but requires a very strong  
understanding of your compiler, linker and runtime link resolver. It  
also requires you to be almost pathological to avoid situations like  
the parent post.

Using the right CFLAGS with the correct -L -I values and at run time  
having DYLD_LIBRARY_PATH set correctly would work. The one thing I'm  
not sure about is, the os x version of -rpath.  When building you  
would want to use the equivalent of -rpath at link time to ensure  
paths to libraries are linked and the runtime library loader doesn't  
get confused.

In general, one probably shouldn't do this as it requires quite a bit  
of effort to maintain. Generally I install test or experimental  
things into their own prefix and use the same shared libraries.  
Again, understand how gcc and dyld resolve includes and library paths  
and set cflags as needed before you build. You could do something  
like the following and have whatever non-port software use the stuff  
installed by the ports system.

export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/opt/local/lib"
CFLAGS="-L/opt/local/lib -I/opt/local/include" ./configure


--
J.