Date: Tue, 28 May 2019 16:51:15 -0700 From: Mark Millard <marklmi@yahoo.com> To: Jason Bacon <bacon4000@gmail.com> Cc: freebsd-ppc@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: <A1146F75-5BBF-4F7D-A293-5BACB060D383@yahoo.com> In-Reply-To: <c257aafa-a32f-dd68-1f6e-7cc9c3c3520d@gmail.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> <1A31ACF2-746A-49D2-80D5-E80392704B4E@yahoo.com> <c257aafa-a32f-dd68-1f6e-7cc9c3c3520d@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-May-28, at 14:57, Jason Bacon <bacon4000 at gmail.com> wrote:
> On 2019-05-28 14:19, Mark Millard via freebsd-ppc wrote:
>>> 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:
>>=20
>> /usr/local/lib/libicui18n.so.64
>> /usr/local/lib/libicuuc.so.64
>>=20
>> were built by the system toolchain but qt5-core was
>> built by something like lang/gcc8 .
>>=20
>> system-clang vs. lang/gcc* need not be the only odd
>> context.
>>=20
>>=20
>=20
> Has anyone explored using ports gcc for *all* ports (except gcc and =
dependencies)?
>=20
> e.g. in make.conf something like
>=20
> .if ${PKGBASE} !=3D "gcc8" && ${PKGBASE} !=3D "gmp" && ...
> USE_GCC=3Dyes
> .endif
>=20
> I've been using this technique very successfully with pkgsrc on =
CentOS, which has basically the same problem with antiquated base =
compilers (CentOS 7 is the current maintstream and it uses gcc 4.8).
>=20
> This eliminates tool chain mixing and only a handful of ports need =
patching to work with legacy gcc.
Such is not a direction that I've been experimenting
with. (But what toolchains work for what ports is
interesting information.)
Some folks pick toolchains by licensing issues. Some of
those might go the direction of avoiding lang/gcc* and
related material when they can, possibly using, say,
devel/llvm80 related materials instead.
But various ports force specific toolchains and some of
those really require what they force: not "portable" code
relative to the toolchains. Some ports do things like
like use llvm infrastructure to build specialized code
generation and the like, just to list an extreme example.
Thus forcing a specific toolchain globally tends to
somewhat limit the range of ports effectively available,
some of that via dependency structures.
poudriere bulk -a (or analogous) experiments take a while.
This would tend to limit such experiments, even if there
were no other issues involved.
Another issue is that what range of toolchains a port
is potentially designed for is generally an upstream
matter. The matching FreeBSD port may support a smaller
range but, generally, is unlikely to support a wider
range.
My experiments are not likely to go the direction of
overriding what all/most ports do for picking toolchains.
=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?A1146F75-5BBF-4F7D-A293-5BACB060D383>