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

[Jason Bacon]

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.