Hi, Am 24.07.2011 um 17:57 schrieb Maciej Bliziński: > Em 22/07/2011 12:56, "Jonathan Craig" <[email protected]> escreveu: > > > > 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. > > We can append anything, soname is a string. > > > PROS: One shared library tree, so only one path for LD_LIBRARY_PATH users. > > Also, an easy to understand runtime failure mode: > "Error: libfoo.so.gcc1 not found." It is obvious what file is needed. > > > CONS: Package construction is trickier. Possibly still confusing for > > end users who are trying to build against our libraries. > > The .so files still need to be in a different directory, like in the libnet > example. > > > 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. > > The main disadvantage would be confusing failure modes. Whether the binaries > would work or not, would be determined by the RPATH order, and in the case of > failure, the given error message would in no way indicate what's wrong or > what to do. It would be something like a missing symbol, snd not something > that points to the sunstudio vs gcc issue.
Rewriting the soname or other linker information is really hard to build into the process. For adding AUX linkage to GAR I make a build, then remove libraries one by one, set for each one a linker adjustment variable and restart the build. This is obivously pretty ugly. Before going this path we must find a simpler approach or this path is dead. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
