[x264-devel] [PATCH 1/2] macosx: version the libraries

Gil Pedersen gil at cmi.aau.dk
Wed Mar 7 17:29:06 CET 2012


On 07/03/2012, at 17.01, Sean McGovern wrote:

> On 3/7/12, Gil Pedersen <gil at cmi.aau.dk> wrote:
>> On 07/03/2012, at 15.04, Sean McGovern wrote:
>> 
>>> On 3/7/12, Gil Pedersen <gil at cmi.aau.dk> wrote:
>>>> What is the rationale behind this change?
>>> 
>>> Versioning parity between the ELF and Mach-O versions of the library.
>> 
>> How so? On Linux the version is not represented in the .so itself, only
>> through a naming convention. Why does Mach-O need the information encoded
>> otherwise?
>> 
> 
> From my Solaris 10 box (another ELF platform):
> 
> $ objdump -x libx264.so | grep SONAME
> SONAME libx264.so.122
> 
> Linux doesn't do this?

You are right, though it is still based on conventions. Also the same information is already coded into the x264 dylib with the current setup.

>>>> It will require a recompile of anything that links against libx264 and
>>>> cause
>>>> incompatible programs to crash when started. I don't see any benefits to
>>>> the
>>>> change when libx264 already has a link time check that will crash the
>>>> calling app when x264_encoder_open() is called.
>>> 
>>> Isn't this also true when the ELF soname changes?
>> 
>> Which of my statements you are referring to?
> 
> An intelligent dynamic linker would refuse to link against this
> library if the calling application requested libx264.so.122 -- which
> seems proper behaviour for us since I don't think we do any backwards
> compatibility testing when we bump the major version.

That depends on your point of view. With the current setup an incorrect dynamic linking will crash once x264_encoder_open() is called. With the proposed change it will either crash immediately (if the lib is newer than expected), or do as it does currently (if the lib is older).

I prefer the more coherent behaviour of the current implementation.

/Gil


More information about the x264-devel mailing list