[oi-dev] GCC rebuilds

[Till Wegmüller]

This is what it was in the past and what is currently achieved by 
mediating links to /usr/lib. We had to change it because we could not 
resolve the openssl version problem with a little enough effort for us 
to achieve. So the proble is not the runtime changing places its 
application being compiled explicitly against gcc-7 in the outside of 
/usr/lib location. And somehow loading in the gcc7 runtime. So the only 
thing left to do is to bump the packages and try to fix them until it is 
fixed. Unfortunately with this specific version of virtualbox we the 
maintainers cannot test as we are missing hardware. So for some reason 
virtualbox and some other libs are still missing and it would be 
wonderfull if some people could bump the Revision if they find such 
libraries.

-Till

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