[MacPorts] #42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0

[MacPorts]

#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