<p>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.</p>
<p>We can append anything, soname is a string.</p>
<p>><br>
> PROS: One shared library tree, so only one path for LD_LIBRARY_PATH users.</p>
<p>Also, an easy to understand runtime failure mode: <br>
"Error: libfoo.so.gcc1 not found." It is obvious what file is needed.</p>
<p>> CONS: Package construction is trickier.  Possibly still confusing for<br>
> end users who are trying to build against our libraries.</p>
<p>The .so files still need to be in a different directory, like in the libnet example. </p>
<p>> 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.  </p>
<p>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.</p>

<p>Maciej</p>