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.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
