[MacPorts] #42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0
MacPorts
noreply at macports.org
Sun Jan 19 21:03:56 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 larryv@…):
Replying to [comment:15 me@…]:
> Apple's dyld is giving a misleading error message (failing to
> distinguish the dylib id - the same string as a file path - from an
> actual file path), which is a bug.
It’s arguably intended behavior and thus would not be considered a bug.
Confusing, but not a bug. Again, if the dylib ID is a complete file path
that does not correspond to the actual library path or contain a special
dyld variable like `@rpath`, then the library is //broken//.
And there happens to be an environment variable that prods `dyld` into
exhibiting the behavior you’re expecting:
{{{
DYLD_PRINT_LIBRARIES
When this is set, the dynamic linker writes to file descriptor 2
(normally standard error) the filenames of the libraries the
program is using. This is useful to make sure that the use of
DYLD_LIBRARY_PATH is getting what you want.
}}}
In any case, this is irrelevant because most of us don’t work at Apple and
can’t change `dyld`.
> > MacPorts is not invoked in any way when you use a port; it only
> > manages dependencies and installation.
>
> And when it does so, it could warn you that your configuration is
> broken so ports it installs can't be expected to work. When it scans
> for linking errors it could check against DYLD_LIBRARY_PATH
No, it couldn’t. `DYLD_*` variables are scrubbed from MacPorts’
environment by `sudo(8)` as a security measure.
--
Ticket URL: <https://trac.macports.org/ticket/42188#comment:16>
MacPorts <http://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list