[csw-maintainers] Shared library placement, take 3
maciej at opencsw.org
Thu Jul 21 09:39:15 CEST 2011
Em 20/07/2011 20:08, "Jonathan Craig" <jcraig at opencsw.org> escreveu:
> On Wed, Jul 20, 2011 at 2:06 PM, Peter FELECAN <pfelecan at opencsw.org>
> > need to use different versions on their own systems. As always, look how
> > Debian solved the issue.
> There are two use cases for this problem:
> Unique SONAMEs ) This is the better behaved use case. In this
> situation multiple versions of the shared libraries can co-exist in
> the same directory. So lets assume we have the app "foo" that
> provides "libfoo" and has a version 1 & 2.
> package contents dependency
> foo1 bin depends on libfoo1
> foo2 bin depends on libfoo2
> libfoo1 so
> libfoo2 so
> libfoo1-dev header depends on libfoo1, conflicts libfoo2-dev
> libfoo2-dev header depends on libfoo2, conflicts libfoo1-dev
> If debug versions of so's then:
> libfoo1-dbg debug-so conficts with libfoo1 (and libfoo1 conflicts with
> This allows multiple bin/so versions to be installed and one version
> of the headers.
What if two maintainers are building packages at the same time and each one
needs a different version of a library?
> We could extend this with CSWalternatives to allow
> switching between header versions but could be confusing if you assume
> the version you want is the current version.
> Non-Unique SONAMEs) Bad developer, bad. Oh well, the packager must
> still deal with it.
In the general case, it is possible to inject an additional soname number to
make the sonames unique.
> I'm not sure of an example package like this to
> check against my ubuntu catalog. This situation calls for either
> making the versions exclusive (using conflicts with) or configuring
> them for there own tree. Using alternatives is a risky undertaking
> because it will almost always eventually cause grief. If alternatives
> puts the .so in a common lib directory and a user builds against it
> then changes the alternative choice, whatever they've built will
Yes, alternatives do not look like a good choice, neither for .so symlinks,
nor for libraries.
> Ultimately, if the library is well behaved then I do think its best to
> place it in a common directory (/opt/csw/lib).
Cool. There is one case which needs consideration: gcc C++ libs vs Solaris
Studio C++ libs. If we compile the same sources with both compilers, we will
get a soname conflict. What should we do: put gcc libs into e.g.
/opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in
/opt/csw/lib? (Or is there another solution?)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the maintainers