MacPorts 1.5.2 now available

[Jason Stelzer]

On Aug 22, 2007, at 9:34 AM, Jay Sachs wrote:

>> export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/opt/local/lib"
>> CFLAGS="-L/opt/local/lib -I/opt/local/include" ./configure
>
> Just to be clear, neither of those excludes /usr/local/ 
> {include,lib} -- they just put /opt/local into the search path. I  
> suspect that you'd really want /opt/local first in the library  
> path, e.g.
>
> export DYLD_LIBRARY_PATH="/opt/local/lib:$DYLD_LIBRARY_PATH"
>

Be careful with DYLD_LIBRARY_PATH at runtime. Depending on which  
application you're using at the time, dyld may use the wrong library  
at runtime.

I alluded to this before, but does anyone know the moral equivalent  
to a -rpath linker directive on os x?

It would help in this situation a great deal. Elf executables can be  
linked in a way that includes path information to the libraries used  
at compile time. The down side to this is that if you go changing  
paths around where stuff is installed, things break. The up side to  
it is that you know what library is used at runtime when a binary is  
executed from a (relatively) sane environment. I'm sure rpath isn't  
bulletproof, but it does help.

I'm not seeing anything similar in the ld or dyld man pages. Without  
this ability you're going to have a problem when you go to launch 2  
different binaries that were compiled with 'the same but different'  
versions of a library.

> I think completely avoiding /opt/local is more hygienic -- that way  
> MP only depends on Apple-provided libraries and on libraries it  
> itself manages.
>
>

Have you tried expressly setting DYLD_FALLBACK_LIBRARY_PATH at  
compile time?  By  default,  it  is  set  to $(HOME)/lib:/usr/local/ 
lib:/lib:/usr/lib. Having $HOME/lib first seems goofy to me, but I  
don't actually have a $HOME/lib. My understanding is that overriding  
this would effectively cut /usr/local out of the library search path  
entirely. Again, I'm just going by the dyld man page. This would at  
least help the compile/upgrade phase of macports by excluding the  
stuff in /usr/local thus achieving your goal of only using macports/ 
apple libraries.


It's just my opinion but I believe that you're best off managing  
systems as a whole. Use macports where possible and install custom  
stuff that leverages your managed packages. The alternative,  
installing the same library in multiple places, is just asking for  
versioning problems that will be very frustrating to track down. If  
you're going to pursue the alternative I recommend finding a way to  
link binaries in such a way that hints as to what path to prefer is  
included for linked libraries. That would make for the sanest setup.  
I just don't happen to know how to do that on a mac.

As to the OP question about using gem with a macports installed  
version of ruby, I can't answer that directly. However, if you had  
(just for instance) a macports install of perl, then it is self  
contained. As long as the right perl is in your path, installing a  
perl module will result in it going under /opt/local (by default). I  
believe ruby is similar.


--
J.