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

[Luca Barbato]

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

lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero