The names aren't mangled with the version number inside the shared library, if that's what you mean, and yes, almost all *nix libraries create a library of the form <b>libfoo.x.y.dylib</b> (or <b>.so</b>, if you prefer linux) but they also almost invariably generate a <b>libfoo.dylib</b> that is a symlink to the "versioned" one, along with a <b>libfoo.x.dylib</b>, where <b>x</b> denotes the "major" version and <b>y</b> denotes the "minor" version. Most libraries are setup in such a way that the "major" version preserves the API so that bugfixes, etc... can be transparently applied to applications without needing those applications to be relinked, whereas major breaking changes force a bump up in the major API version number, thus forcing a relink. My guess is the dynamic linker is getting confused by the nonstandard naming convention used by libx264, thinking that the <b>125</b> in <b>libx264.125.dylib</b> is a major version number.<div>
-E<br><br><div class="gmail_quote">On Sun, Oct 7, 2012 at 8:09 AM, Jan Ekström <span dir="ltr"><<a href="mailto:jeebjp@gmail.com" target="_blank">jeebjp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2012/10/07 1:45, Elliot Saba wrote:<br>
> Hello, all. I'm here trying to figure out why, on my machine (OSX 10.8.2, clang compiler, using Homebrew as a package manager) my dynamic linker picks out the "versioned" x264 library, not the generic one. As I am on OSX, this turns out to be *libx264.125.dylib*, as opposed to the generic symlink *libx264.dylib*.<br>
<div class="im">><br>
> This is a problem as whenever libx264 gets a version bump, I then have to re-link all software that uses libx264. A real-world example:<br>
><br>
</div>> *$ otool -L `which ffmpeg` | grep x264*<br>
> */Users/sabae/.homebrew/lib/libx264.125.dylib (compatibility version 0.0.0, current version 0.0.0)*<br>
><br>
> No other software on my computer does this, and it's not something inherent in the Homebrew method of compiling ffmpeg, because even if I download ffmpeg-1.0 source, configure with *--enable-gpl --enable-libx264* and *make*, I still end up with an *ffmpeg* executable dynamically linked to *libx264.125.dylib*.<br>
><br>
> Thank you,<br>
> -E<br>
><br>
><br>
> _______________________________________________<br>
> x264-devel mailing list<br>
> <a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>
> <a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
Linking to the versioned library is intentional as far as I can tell. Every time the API version gets bumped, there is absolutely no guarantee that what you were linking will still work (actually, I'm pretty sure it will fail because the main API calls are IIRC also "versioned" as well). This is not limited to x264, either. Actually, most of the libraries I have on the *nix systems I have access to have "versioned" library files.<br>
<br>
Jan E<br>
_______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>
<a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
</blockquote></div><br></div>