<p>Em 25/07/2011 15:54, "Dagobert Michelsen" <<a href="mailto:dam@opencsw.org">dam@opencsw.org</a>> escreveu:<br>
><br>
> Hi,<br>
><br>
> Am 24.07.2011 um 17:57 schrieb Maciej Bliziński:<br>
> > Em 22/07/2011 12:56, "Jonathan Craig" <<a href="mailto:jcraig@opencsw.org">jcraig@opencsw.org</a>> escreveu:<br>
> > ><br>
> > > 2011/7/21 Maciej Bliziński <<a href="mailto:maciej@opencsw.org">maciej@opencsw.org</a>>:<br>
> > > ><br>
> > > > Cool. There is one case which needs consideration: gcc C++ libs vs Solaris<br>
> > > > Studio C++ libs. If we compile the same sources with both compilers, we will<br>
> > > > get a soname conflict. What should we do: put gcc libs into e.g.<br>
> > > > /opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in<br>
> > > > /opt/csw/lib? (Or is there another solution?)<br>
> > > ><br>
> > > This problem is one we will have to solve on our own as debian doesn't<br>
> > > face this issue AFAIK.  Well I see three approaches, but there may be<br>
> > > more:<br>
> > ><br>
> > > 1) Place the the style of the library used by our binaries into the<br>
> > > common directory and the other into its own tree<br>
> > > (/op/csw/lib/[gcc|sunstudio]).<br>
> > ><br>
> > > PROS: Our binaries always find shared library in a single place.<br>
> > > Could help with customers who are forced to use LD_LIBRARY_PATH<br>
> > > settings.<br>
> > > CONS: Confusing, how is one to know which style a given library uses<br>
> > > beyond looking for a README.<br>
> > ><br>
> > > 2) Always place sunstudio into the common and gcc into its own tree<br>
> > > (or vise-versa)<br>
> > ><br>
> > > PROS: Not confusing as to which directory holds which files.  Our<br>
> > > developers have resources to determine their RPATH needs at build<br>
> > > time.<br>
> > > CONS: LD_LIBRARY_PATH, while not recommended, should have a note about<br>
> > > default including all of the shared library trees.<br>
> > ><br>
> > > 3) Use the approach for poorly behaved libraries and insert a minor<br>
> > > release version to indicate sunstudio/gcc style library.  If we always<br>
> > > use a most minor version component of ".999" for the gcc style then we<br>
> > > can force the link against the correct style.<br>
> ><br>
> > We can append anything, soname is a string.<br>
> ><br>
> > > PROS: One shared library tree, so only one path for LD_LIBRARY_PATH users.<br>
> ><br>
> > Also, an easy to understand runtime failure mode:<br>
> > "Error: libfoo.so.gcc1 not found." It is obvious what file is needed.<br>
> ><br>
> > > CONS: Package construction is trickier.  Possibly still confusing for<br>
> > > end users who are trying to build against our libraries.<br>
> ><br>
> > The .so files still need to be in a different directory, like in the libnet example.<br>
> ><br>
> > > I'm not wedded to any given approach at this time as my packages have<br>
> > > all been pretty straight forward.  I would lean towards #2 as its the<br>
> > > simplest in terms of construction and should be easily understood by<br>
> > > our customers.<br>
> ><br>
> > 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.<br>

><br>
> Rewriting the soname or other linker information is really hard to build into the<br>
> process. For adding AUX linkage to GAR I make a build, then remove libraries one by one,<br>
> set for each one a linker adjustment variable and restart the build. This is<br>
> obivously pretty ugly. Before going this path we must find a simpler approach or<br>
> this path is dead.</p>
<p>Why rewriting? It would be my last choice. It is cleaner to patch the sources to modify the soname right from the beginning.</p>
<p>Patching sources might be trivial or hard depending on the build system, but I expect that it is possible to teach checkpkg to detect whether built sonames have the right format. This way, it would be clear for the maintainer, whether they got it right or not.</p>

<p>Maciej<br>
</p>