[csw-maintainers] Shared library placement, take 3

Jonathan Craig jcraig at opencsw.org
Fri Jul 22 13:56:34 CEST 2011


2011/7/21 Maciej Bliziński <maciej at opencsw.org>:
>
> 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?)
>
This problem is one we will have to solve on our own as debian doesn't
face this issue AFAIK.  Well I see three approaches, but there may be
more:

1) Place the the style of the library used by our binaries into the
common directory and the other into its own tree
(/op/csw/lib/[gcc|sunstudio]).

PROS: Our binaries always find shared library in a single place.
Could help with customers who are forced to use LD_LIBRARY_PATH
settings.
CONS: Confusing, how is one to know which style a given library uses
beyond looking for a README.

2) Always place sunstudio into the common and gcc into its own tree
(or vise-versa)

PROS: Not confusing as to which directory holds which files.  Our
developers have resources to determine their RPATH needs at build
time.
CONS: LD_LIBRARY_PATH, while not recommended, should have a note about
default including all of the shared library trees.

3) Use the approach for poorly behaved libraries and insert a minor
release version to indicate sunstudio/gcc style library.  If we always
use a most minor version component of ".999" for the gcc style then we
can force the link against the correct style.

PROS: One shared library tree, so only one path for LD_LIBRARY_PATH users.
CONS: Package construction is trickier.  Possibly still confusing for
end users who are trying to build against our libraries.

I'm not wedded to any given approach at this time as my packages have
all been pretty straight forward.  I would lean towards #2 as its the
simplest in terms of construction and should be easily understood by
our customers.  Option 3 is intriguing but I worry that it would be
overly complicated for little gain.

Thoughts?

Jon


More information about the maintainers mailing list