powerpc64 system-clang-8 based context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/local/lib/gcc8/libstdc++.so.6

[Mark Millard]

[I forgot to mention of the combination: gcc and libc++.=

On 2019-May-24, at 12:11, Mark Millard <marklmi at yahoo.com> wrote:

> On 2019-May-24, at 11:25, Mark Linimon <linimon at lonesome.com> wrote:
> 
>> On Thu, May 23, 2019 at 10:33:35PM -0700, Mark Millard via freebsd-toolchain wrote:
>>> That is no matter what the system compiler is for powerpc64.
>>> 
>>> This lead to the below mixing of libstdc++.so.6 and libc++/libcxxrt . . .
>> 
>> Yeah.  This is probably my fault.
>> 
>> We've baked the assumption into ports that "powerpc64 implies gcc in base".
>> You're the first person to color outside the lines I think :-)
>> 
>> I'm going to start an internal discussion about what the "real" fix is.
>> I consider what we've done in some places to not be the "real" fix because
>> they assume _either_ llvm _or_ gcc in base.  This would fix your specific
>> problem but not the general problem of someone installing both and then
>> switching back and forth for testing.
> 
> Plus qt5 is outside the range of gcc 4.2.1 to cover, so for it
> a usable "gcc in base" would mean base/gcc or some such substitution.
> But base/gcc does not imply any version of libstdc++ is in use either:
> same problem as system-clang-8-based if something like lang/gcc8 is
> used for qt5.
> 
> Even if libstdc++ was (hypothetically) used, the vintage from
> base/gcc or devel/*-gcc sorts of materials would not generally
> match lang/gcc8 or whatever compiler:c++11-lib and the like
> might default to.
> 
> For the likes of qt5, care must be taken that, for example,
> devel/icu and its:
> 
> /usr/local/lib/libicui18n.so.64
> /usr/local/lib/libicuuc.so.64
> 
> vs. qt5: they must use the same c++ library and vintage.
> 
> Then there are things that really could use gcc 4.2.1 from
> base: mixed libstdc++ vintages could result, even if some
> port lang/gcc* toolchain is used.
> 
> Definitely a messy context.
> 
> The failing behavior (program crash very early when starting)
> was not obviously tied to c++ library mixes being involved. It
> would be handy if some stage of building/installing/running
> caught the presence of such a bad combination and was explicit
> about it.

I probably should have mentioned using the likes of
base/binutils and base/gcc and ending up with a gcc
based system c and c++ but a system libc++ / libcxxrt
instead of libstdc++ . This would still make for the
odd mix of libc++ / libcxxrt vs. libstdc++ if:

/usr/local/lib/libicui18n.so.64
/usr/local/lib/libicuuc.so.64

were built by the system toolchain but qt5-core was
built by something like lang/gcc8 .

system-clang vs. lang/gcc* need not be the only odd
context.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)