[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
lu
--
Luca Barbato
Gentoo/linux Developer Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero
More information about the ffmpeg-devel
mailing list