<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 1, 2023 at 5:28 PM Thomas Wagner <<a href="mailto:tom-oi-dev@tom.bn-ulm.de">tom-oi-dev@tom.bn-ulm.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Aug 01, 2023 at 05:09:26PM +0200, Marcel Telka wrote:<br>
> On Tue, Aug 01, 2023 at 02:38:32PM +0100, Peter Tribble wrote:<br>
> > On Tue, Aug 1, 2023 at 6:41 AM Stephan Althaus <<br>
> > <a href="mailto:Stephan.Althaus@duedinghausen.eu" target="_blank">Stephan.Althaus@duedinghausen.eu</a>> wrote:<br>
> > > We are stumbling over some faults with regard to the GCC Version change.<br>
> > <br>
> > Perhaps this would be an opportune moment to reconsider the way that<br>
> > libstdc++<br>
> > (and generally the whole gcc/g++ runtime) is packaged, and to go for the<br>
> > obvious<br>
> > and supported route of only shipping one copy of the runtime - the one<br>
> > corresponding to<br>
> > the latest version of the compiler that you ship (gcc11 ?), and putting it<br>
> > directly in<br>
> > /usr/lib.<br>
> <br>
> The obvious question now is:<br>
> Why it was not done that way since beginning?<br>
<br>
Placing a library in /usr/lib/ that caused version incompatibilties in the past<br>
and most likely will continue to do so every now an then is not the best idea.<br>
Despite the promised compatibility in newer versions of the runtime libs.<br>
In rare cases we've seen binaries compiled with an old gcc version not being<br>
compatible with the latest gcc runtime libs. Especially for C++.<br></blockquote><div><br></div><div>That would be a plain and simple bug; the gcc team take binary compatibility very seriously,<br>and actually understand things like shared library versioning properly. To the extent that we<br>have had a forward-compatible libstdc++ that manages to cleanly handle the fact that the<br>C++ ABI itself changed (leading to the library transparently handling the dual ABI from gcc<br>5.1 onwards) along with multiple versions of the C++ language since about GCC 3.4.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Therefore the SFE packaging project points libs and binaries to a<br>
versioned directory to get the version of runtime libs loaded they have<br>
been compiled with.<br>
e.g. binaries look first in /usr/gcc-sfe/4.9/lib and /usr/gcc-sfe/11/lib<br>
for the runtime libs in an early stage.<br>
<br>
Regards<br>
Thomas<br>
<br>
<br>
_______________________________________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a><br>
<a href="https://openindiana.org/mailman/listinfo/oi-dev" rel="noreferrer" target="_blank">https://openindiana.org/mailman/listinfo/oi-dev</a><br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">-Peter Tribble<br><a href="http://www.petertribble.co.uk/" target="_blank">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/" target="_blank">http://ptribble.blogspot.com/</a></div></div>