Re: 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 via freebsd-ppc <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.ppc,gmane.os.freebsd.devel.toolchain,gmane.os.freebsd.devel.ports |
|---|---|
| Message-ID | <[email protected]> |
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. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "[email protected]"