2011/7/21 Maciej Bliziński <[email protected]>: > > 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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
