[MacPorts] #42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0
#42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0 --------------------------------------------+------------------------------ Reporter: me@… | Owner: macports- Type: defect | tickets@… Priority: Normal | Status: new Component: ports | Milestone: Keywords: ffmpeg libogg dependency error | Version: 2.2.1 | Port: ffmpeg --------------------------------------------+------------------------------ After updating with $(`sudo port selfupdate`) and $(`sudo port upgrade outdated`), and repeating until "`Nothing to upgrade.`", $(`ffmpeg`) gives this output regardless of arguments: {{{ dyld: Library not loaded: /opt/local/lib/libogg.0.dylib Referenced from: /opt/local/bin/ffmpeg Reason: Incompatible library version: ffmpeg requires version 9.0.0 or later, but libogg.0.dylib provides version 6.0.0 Trace/BPT trap: 5 }}} The output is the same with the current ffmpeg (2.1.3_1) and after reactivating the oldest installed ffmpeg (2.1.1_0). I only have the current libogg installed (1.3.1_0), and the output was not affected by uninstalling libogg with $(`port -f uninstall libogg`) then reinstalling. -- Ticket URL: <https://trac.macports.org/ticket/42188> MacPorts <http://www.macports.org/> Ports system for OS X
#42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0 ---------------------+-------------------------------------------- Reporter: me@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: ffmpeg libogg dependency error Port: ffmpeg | ---------------------+-------------------------------------------- Comment (by cal@…): What is the output of `otool -L /opt/local/lib/libogg.0.dylib`? What does `env | grep DYLD_` print? -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0 ---------------------+------------------------ Reporter: me@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: ffmpeg | ---------------------+------------------------ Changes (by cal@…): * cc: devans@… (added) * keywords: ffmpeg libogg dependency error => * owner: macports-tickets@… => jeremyhu@… -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0 ---------------------+---------------------- Reporter: me@… | Owner: devans@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: ffmpeg | ---------------------+---------------------- Changes (by devans@…): * owner: jeremyhu@… => devans@… * status: new => assigned * cc: devans@… (removed) * cc: jeremyhu@… (added) Comment: It does appear that you have an older version of libogg installed. The current version 1.3.1_0 (the one ffmpeg was built with) says {{{ $ otool -L /opt/local/lib/libogg.0.dylib /opt/local/lib/libogg.0.dylib: /opt/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.1.0) }}} which is what ffmpeg is looking for (library version 9.0 or greater). However, the error message indicates that the version of libogg installed on your machine is only library version 6.0. Answering cal's questions above would be a start to understanding why that is. You might also try {{{ port installed libogg }}} to see what versions of libogg are installed and which is active. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#42188: Dependency error in ffmpeg 2.1.3_1 on libogg 1.3.1_0 ---------------------+---------------------- Reporter: me@… | Owner: devans@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: | Keywords: Port: ffmpeg | ---------------------+---------------------- Comment (by me@…): {{{ polyergic@laconic : ~ $ otool -L /opt/local/lib/libogg.0.dylib /opt/local/lib/libogg.0.dylib: /opt/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) polyergic@laconic : ~ $ env | grep DYLD DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib: DYLD_LIBRARY_PATH=/usr/local/xuggler/lib polyergic@laconic : ~ $ }}} This makes no sense; ffmpeg says it has version 6.0.0, but otool says it has version 9.1.0. There is another libogg.0.dylib in $DYLD_LIBRARY_PATH: {{{ polyergic@laconic : ~ $ otool -L $DYLD_LIBRARY_PATH/libogg.0.dylib /usr/local/xuggler/lib/libogg.0.dylib: /usr/local/lib/libogg.0.dylib (compatibility version 6.0.0, current version 6.3.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) polyergic@laconic : ~ $ }}} So is ffmpeg not falling back to the fallback, and reporting the wrong path for the one it tries to load? DYLD_LIBRARY_PATH was changed by installing the OSP Tracker (http://www.cabrillo.edu/~dbrown/tracker/), which doesn't seem to be available as a port. If the fallback path doesn't work, what configuration will be compatible with both at once? -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#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 | ----------------------+---------------------- Changes (by cal@…): * status: assigned => closed * resolution: => invalid Comment: `DYLD_LIBRARY_PATH` on OS X does not behave like `LD_LIBRARY_PATH` on Linux. Despite this fact, several tools advise setting `DYLD_LIBRARY_PATH` on OS X in their documentation. This can lead to the problem you are seeing at hand – setting `DYLD_LIBRARY_PATH` makes the loader prefer any file with the same basename (in this case `libogg.0.dylib`) from the paths listed in `DYLD_LIBRARY_PATH` to those at the URL the binary linked to (which is what you see in the output of `otool -L /opt/local/bin/ffmpeg`). As a consequence, just must not have `DYLD_LIBRARY_PATH` set when using ffmpeg. As a precaution, you should only set it when you need to run whatever software requires it. In fact, it is advisable to modify the software requiring the variable in a way that it no longer needs it. You may do so using `install_name_tool`, by changing the paths referenced by its binaries and libraries to absolute ones referencing the appropriate versions of the libraries in `/usr/local/xuggler/lib`. You may have to adjust this for the binaries in `/usr/local/xuggler/bin`, `/usr/local/xuggler/sbin` and `/usr/local/xuggler/lib`. If you can, please advise upstream of xuggler (or any other location that gave you the advice to set `DYLD_LIBRARY_PATH`) to avoid this and instead fix the paths in the binaries. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
#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 me@…): I'm not sure this should be closed yet; ffmpeg is still misreporting the error, saying it's loading a different file than it's actually loading, and not using the fallback. Do you have a link describing the behavior of DYLD_LIBRARY_PATH? From what you say it sounds like the "right way" is to never define it at all. Does `install_name_tool` work for all executables or just for macports executables? Unsetting DYLD_LIBRARY_PATH and DYLD_OVERRIDE_LIBRARY_PATH does resolve the error. I didn't set them by hand based on some advice, it was done automatically either by the Tracker installer or an installer for a dependency. If the variable acts as an override, why isn't it DYLD_OVERRIDE_LIBRARY_PATH? -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#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 devans@…): ffmpeg is just trying to load the first thing that it finds. The problem is that because of your system configuration, that is /usr/local/lib/libogg.0.dylib which is an older version than the Macports file at /opt/local/lib/libogg.0.dylib. We advise not to try and mix MacPorts software with non-Macports software and particularly not software that is installed in /usr/local which can interfere (as in this case). MacPorts software is designed to not need DYLD_LIBRARY_PATH as cal has indicated. If you unset this variable or set it to /opt/local/lib ffmpeg should work fine. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#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 jeremyhu@…):
I'm not sure this should be closed yet; ffmpeg is still misreporting the error, saying it's loading a different file than it's actually loading, and not using the fallback.
It's not reporting the *FILE* it's reporting the *DYLIB ID*. I understand your confusion, but it is correct.
Do you have a link describing the behavior of DYLD_LIBRARY_PATH
Read the dyld man page.
From what you say it sounds like the "right way" is to never define it at all.
YES! No user should ever define it. No released software should rely on it being set. If you *REALLY* need something like it, use DYLD_FALLBACK_LIBRARY_PATH
Does install_name_tool work for all executables or just for macports executables?
Anything mach-o
Unsetting DYLD_LIBRARY_PATH and DYLD_OVERRIDE_LIBRARY_PATH does resolve the error.
As expected
I didn't set them by hand based on some advice, it was done automatically either by the Tracker installer or an installer for a dependency.
Yes, likely xuggler. (http://www.xuggle.com ?). Go yell at them.
If the variable acts as an override, why isn't it DYLD_OVERRIDE_LIBRARY_PATH?
It isn't an override. It does what it's documented to do. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#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 jeremyhu@…): Replying to [comment:7 devans@…]:
ffmpeg is just trying to load the first thing that it finds. The problem is that because of your system configuration, that is /usr/local/lib/libogg.0.dylib which is an older version than the Macports file at /opt/local/lib/libogg.0.dylib.
No, the file is actually /usr/local/xuggler/lib/libogg.0.dylib which has a dylib id of /usr/local/lib/libogg.0.dylib ... yet another issue to report to xuggler (and likely the reason they tried to "fix" the issue with DYLD_LIBRARY_PATH). -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
#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 devans@…): True. For discussion of why MacPorts uses /opt/local and /usr/local/whatever is discouraged see the corresponding items in the [wiki:FAQ MacPorts FAQ]. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X
#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
#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 jeremyhu@…): Replying to [comment:11 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.
It isn't a bug. It is *correctly* reporting the dylib id of the link being resolved. That is often the path name but not always. This is clear when you have a link that is using a relative path rather than an absolute on. For example: {{{ Dyld Error Message: Library not loaded: @rpath/My.framework/Versions/A/My Referenced from: /Applications/My.app/Contents/MacOS/My Reason: image not found }}} -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X
#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 me@…): Filed Xuggler bug: http://code.google.com/p/xuggle/issues/detail?id=311 IME Apple bug reports are useless, so I won't bother. MacPorts could give a warning when DYLD_LIBRARY_PATH is set. If the library's loaded at runtime, ffmpeg could make the error message less misleading by giving the path and id separately, and noting that dyld does not report the path of the library it loads. It would help if there were a reference for DYLD_LIBRARY_PATH that more clearly stated not just what it does but what it should and should not be used for. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:13> MacPorts <http://www.macports.org/> Ports system for OS X
#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:13 me@…]:
IME Apple bug reports are useless, so I won't bother.
That’s fine, because there is no Apple bug here.
MacPorts could give a warning when DYLD_LIBRARY_PATH is set.
MacPorts is not invoked in any way when you use a port; it only manages dependencies and installation.
It would help if there were a reference for DYLD_LIBRARY_PATH that more clearly stated not just what it does but what it should and should not be used for.
The `dyld(1)` man page does mention one use case, which is more or less the //only// use case. {{{ DYLD_LIBRARY_PATH This is a colon separated list of directories that contain libraries. The dynamic linker searches these directories before it searches the default locations for libraries. It allows you to test new versions of existing libraries. }}} Common sense suggests that prepending to the default library search path can easily cause shadowing problems. Imagine a program that added `/usr/local/bin/foobar` to the beginning of your `$PATH`; now imagine that that directory contained broken versions of `bash`, `ls`, `ssh`, and so on. Setting `DYLD_LIBRARY_PATH` is analogous to prepending to `$PATH`; setting `DYLD_FALLBACK_LIBRARY_PATH` is kind of like appending to `$PATH`. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X
#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 me@…): Replying to [comment:14 larryv@…]:
Replying to [comment:13 me@…]:
IME Apple bug reports are useless, so I won't bother.
That’s fine, because there is no Apple bug here.
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. \\
MacPorts could give a warning when DYLD_LIBRARY_PATH is set.
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, predict what the misleading error messages will be, and clarify them individually. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:15> MacPorts <http://www.macports.org/> Ports system for OS X
#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
#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 jeremyhu@…): Replying to [comment:15 me@…]:
Replying to [comment:14 larryv@…]:
Replying to [comment:13 me@…]:
IME Apple bug reports are useless, so I won't bother.
That’s fine, because there is no Apple bug here.
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.
Yes, I actually filed an enhancement request yesterday to provide this extra information in dlerror(), but as Larry mentioned, you can use DYLD_PRINT_LIBRARIES to debug issues like this. The "Library not loaded:" line is correct. The fact that you are confusing the dylib id and the path of the file actually loaded is unfortunate but not really a bug. The behavior is not a bug.
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, predict what the misleading error messages will be, and clarify them individually.
This isn't a linking error. It's an issue at load time. ffmpeg linked successfully. Replying to [comment:16 larryv@…]:
In any case, this is irrelevant because most of us don’t work at Apple and can’t change `dyld`.
Note that dyld is OSS, and if you really care about fixing this error message, I'll pass along a patch for you. Otherwise, you'll have to wait until Nick (or I) get some cycles to make the change. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:17> MacPorts <http://www.macports.org/> Ports system for OS X
#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:17 jeremyhu@…]:
Note that dyld is OSS
Oops, I’d forgotten about that. :P
and if you really care about fixing this error message, I'll pass along a patch for you.
Sure, I could update `ld64` (I presume?) tomorrow. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:18> MacPorts <http://www.macports.org/> Ports system for OS X
#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@…): Replying to [comment:18 larryv@…]:
Sure, I could update `ld64` (I presume? or would it be `dyld-headers`?) tomorrow.
It's `dyld`: http://opensource.apple.com/source/dyld/dyld-239.3/. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:19> MacPorts <http://www.macports.org/> Ports system for OS X
#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:19 cal@…]:
It's `dyld`: http://opensource.apple.com/source/dyld/dyld-239.3/.
Right, but I assumed Jeremy was talking about updating some port. I guess he meant manually compiling a patched `dyld`. -- Ticket URL: <https://trac.macports.org/ticket/42188#comment:20> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts