[MacPorts] #42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0
MacPorts
noreply at macports.org
Sat Jan 18 19:19:54 PST 2014
#42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0
----------------------+----------------------
Reporter: me@… | Owner: devans@…
Type: defect | Status: closed
Priority: Normal | Milestone:
Component: ports | Version: 2.2.1
Resolution: invalid | Keywords:
Port: ffmpeg |
----------------------+----------------------
Comment (by cal@…):
It's actually not ffmpeg misreporting this, but dyld, the dynamic loader
on OS X. I'm not sure for what reasons it reports the incorrect path, but
I suppose it just prints the path referenced from the executed binary
(that is, ffmpeg in this case). The same applies to the naming of the
variables. Since MacPorts is not in control of the loader, this is not our
bug to fix, but Apple's, if any.
The behavior of the `DYLD_*` variables is explained in the manpage for
dyld, i.e. `man 1 dyld` on your system. There it clearly states: "The
dynamic linker searches these directories before it searches the default
locations for libraries. It allows you to test new versions of existing
libraries." This is appropriate and acceptable use of `DYLD_LIBRARY_PATH`.
Since this is something only developers should be doing, it is an error to
use `DYLD_LIBRARY_PATH` in any deployment situation – so yes, it is the
right way to never define it at all, unless you absolutely know what
you're doing.
`install_name_tool` is a tool shipped by Apple that works on all Mach-O
(that is, Mac) binaries, so yes, it will also work for non-MacPorts
binaries.
Setting `DYLD_LIBRARY_PATH` in an installer automatically certainly is a
bug, considering the fallout this can have on other software (like you
just saw).
I closed this bug as invalid, because there's nothing MacPorts can do at
this point. We cannot avoid users (or software on behalf of users) setting
these environment variables and we cannot detect this situation before the
loader does.
--
Ticket URL: <https://trac.macports.org/ticket/42188#comment:11>
MacPorts <http://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list