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-...@tom.bn-ulm.de
<mailto:tom-oi-...@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.alth...@duedinghausen.eu
<mailto:stephan.alth...@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@openindiana.org <mailto:oi-dev@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@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
