Date: Tue, 28 May 2019 16:57:47 -0500 From: Jason Bacon <bacon4000@gmail.com> To: 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: <c257aafa-a32f-dd68-1f6e-7cc9c3c3520d@gmail.com> In-Reply-To: <1A31ACF2-746A-49D2-80D5-E80392704B4E@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> <1A31ACF2-746A-49D2-80D5-E80392704B4E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>>
>> 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.
>
>
Has anyone explored using ports gcc for *all* ports (except gcc and
dependencies)?
e.g. in make.conf something like
.if ${PKGBASE} != "gcc8" && ${PKGBASE} != "gmp" && ...
USE_GCC=yes
.endif
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).
This eliminates tool chain mixing and only a handful of ports need
patching to work with legacy gcc.
--
Earth is a beta site.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c257aafa-a32f-dd68-1f6e-7cc9c3c3520d>