[Ffmpeg-devel] [patch] make SONAME encoding optional

Luca Barbato lu_zero
Sun Dec 18 13:05:01 CET 2005

Jacob Meuser wrote:
> SONAME is generally thought of as uncecessary complication by OpenBSD devs.

I don't like it...

> $ find /usr/lib -name \*.so\* | wc -l
>         66
> $ find /usr/lib -name \*.so\* | xargs readelf -a | grep SONAME
>  0x000000000000000e (SONAME)             Library soname: [libstdc++.so.40.0]
> $ 
> I'm not sure why libstdc++ has SONAME as opposed to the other system libs.

Say that is the only thing that may be slotted or that changes its abi 
for sure, thus breaking your system horribly on mismatch, even accidental.

> also, libtool does not encode SONAME on OpenBSD.

interesting and sad.

>  0x000000000000000e (SONAME)             Library soname: [libxvidcore.so.4]
> hmmm, looks like xvidcore needs to be fixed.

since is the only one correct ^^?

> anyway, it's mostly a matter of simplification.  you can see the major
> and minor versions in the name of the library itself, no need to go
> digging into the binary.

Is just a matter of convention and linking practice.

> no symlinks for libfoo.so -> libfoo.so.X.X either.
> so, it's very clean and easy to see what's going on.  also makes it
> easy to have multiple library versions, since there won't be any
> filename clash; you can only have one libfoo.so.

so you have to link using .so.$version or the linker has to iterate for 
each file that match the name within the libdirs and pick the best version?

> of course, libraries MUST use proper "Sun style" versioning in this
> scheme, but it seems most library authors do this anyway.  of course
> there are many out there that don't use any versioning, be it SONAME
> or the library name itself.  in such cases, the port maintainers
> have to add this themselves.  FreeBSD has a bit about this in their
> developer's handbook:

> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/policies-shlib.html

Ok, it isn't really clear about if you have to make the lib with a 
.$version on link time or later btw.

> there are some other things in the Makefiles that could be more
> consistent.  for example,

> libavformat is using SLIBPREF, while libavutil hardcodes 'lib'.

my latest patch should handle part of it



Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader

More information about the ffmpeg-devel mailing list