Date: Fri, 7 Jun 2019 10:42:45 -0500 From: Jason Bacon <bacon4000@gmail.com> To: Mark Millard <marklmi@yahoo.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: <fadcc84e-2492-e5ea-df5b-608e1f01afaf@gmail.com> In-Reply-To: <A1146F75-5BBF-4F7D-A293-5BACB060D383@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> <c257aafa-a32f-dd68-1f6e-7cc9c3c3520d@gmail.com> <A1146F75-5BBF-4F7D-A293-5BACB060D383@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-05-28 18:51, Mark Millard wrote:
>
> 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.
>>>>
>>>> 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.
> 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.
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
Interesting points, thanks.
What I was really thinking of is simply using a GCC package in place of
the base GCC, but still allowing individual ports to override.
I realize this would require a bit more logic than I alluded to.
One of the immediate goals would be to eliminate redundant checks
sprinkled across the ports tree, especially
.if ${CHOSEN_COMPILER_TYPE} == gcc
USE_GCC=yes
.endif
for ports that won't build with GCC 4.2.
Cheers,
JB
--
Earth is a beta site.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fadcc84e-2492-e5ea-df5b-608e1f01afaf>