#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