Date: Tue, 28 May 2019 12:19:12 -0700 From: Mark Millard <marklmi@yahoo.com> To: Mark Linimon <linimon@lonesome.com> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, ports-list freebsd <freebsd-ports@freebsd.org>, Jan Beich <jbeich@FreeBSD.org> Subject: 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 Message-ID: <1A31ACF2-746A-49D2-80D5-E80392704B4E@yahoo.com> In-Reply-To: <DC1266E8-841F-45DD-A649-7B75D63C726B@yahoo.com> References: <8B8355C5-731B-4F03-AA98-11324C618D3C@yahoo.com> <590AAD80-8D2F-4F7A-8910-001D72A5E666@yahoo.com> <22D9DF10-E58A-49E5-8372-CC9D263A7C76@yahoo.com> <33026AD5-9CB0-43CB-84EA-5B2B914A7EB0@yahoo.com> <CA16609F-0AEA-46B0-A8CE-9280A4E90058@yahoo.com> <3B3EACF3-00D8-48B7-A3C0-8AA6E0279041@yahoo.com> <20190524182522.GA17299@lonesome.com> <DC1266E8-841F-45DD-A649-7B75D63C726B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I forgot to mention of the combination: gcc and libc++.=3D 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: >=20 >> 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. >>>=20 >>> This lead to the below mixing of libstdc++.so.6 and libc++/libcxxrt = . . . >>=20 >> Yeah. This is probably my fault. >>=20 >> 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 :-) >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 > For the likes of qt5, care must be taken that, for example, > devel/icu and its: >=20 > /usr/local/lib/libicui18n.so.64 > /usr/local/lib/libicuuc.so.64 >=20 > vs. qt5: they must use the same c++ library and vintage. >=20 > 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. >=20 > Definitely a messy context. >=20 > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1A31ACF2-746A-49D2-80D5-E80392704B4E>