From owner-freebsd-ppc@freebsd.org Fri Jun 7 15:42:48 2019 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4904415B02D5 for ; Fri, 7 Jun 2019 15:42:48 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 517027736D for ; Fri, 7 Jun 2019 15:42:47 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-io1-xd44.google.com with SMTP id e5so1759590iok.4 for ; Fri, 07 Jun 2019 08:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=qRX0nDP/gEMS+RuaXv8IYPCxusd/nMh+3P77XrTGeGU=; b=PLmBbQSfVIu8tIZR7gAtNHDmpnTnq86KEThDuvv88g1YlNTKiJv/jnWPJcMqrN7SwF BIoL9dD6CPDT43FJFqStqFHt7eXwG8XazPcK2yxs12QEdeK9BoCr36KxTxDIN3yzhBo7 Q1cCjwcx88HCs7gE5B0pUU9ENFzIELxXN2PytbcOa8mDSvwnurSGtgaxe+QUUAn5IqGc x6uzQsBZkeDRZQRAgAn7Ya3IxPqXzZ6hTauW2migh/0elSPCfM6Re76p788XDqIfBdFH U6kAJKdKX9AIXsrwWAM1f0jCkudyORrnonbjeK1fWzcct6shSJVhaFxnfjCr/aF6/OB5 hQag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=qRX0nDP/gEMS+RuaXv8IYPCxusd/nMh+3P77XrTGeGU=; b=Ko8NoWqvf7hcAN1wUGBh0G29F5cLw86w9i/0cZmQXTu57fEQgpGDgWnIm2CEVcD8ao /UzeU66g5Yex5kmtSxdBJRXUez6jjnq+CLMMa2GrMtnhPhfyPm9pv+UhW4Gzc4ZaxTa+ TfQqIgYSOIRPHg3Kgg3KJMwm1eYBY+lrV25Q02sEIYX8G7SgJrTO7z4u4spZFe99bdXM sVewEeR/kHfTR8rb8Gt2EL0Iysl85Nibkcv2lZa5bsjRuu56LVNflN8GHxvtPXRGSIPn H5qYWUruZM5h/6E0AGRWLDntIluibkkI1GGjQIZNtyzKNUBMgVJw2zGmjaRJ623jd+H3 TgLQ== X-Gm-Message-State: APjAAAWPbweNQ7YYdRmeqozhDsYOEFspUgqV65XEe2TdHYkLnaIYGWmU h99XkP+WqkdW/flfoawex6G0kOF5 X-Google-Smtp-Source: APXvYqyt4vVCoXPmOsTtKVuL/Ssf14T3rcNHa1xJgUCVcJ/6yD68ejTWqxedOU5gu5AHc9oknqYnsQ== X-Received: by 2002:a6b:6505:: with SMTP id z5mr11444873iob.295.1559922166361; Fri, 07 Jun 2019 08:42:46 -0700 (PDT) Received: from manatee.acadix.biz (cpe-174-102-163-140.wi.res.rr.com. [174.102.163.140]) by smtp.gmail.com with ESMTPSA id w194sm986413itb.33.2019.06.07.08.42.45 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 08:42:45 -0700 (PDT) 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 To: Mark Millard Cc: freebsd-ppc@freebsd.org 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> <3B3EACF3-00D8-48B7-A3C0-8AA6E0279041@yahoo.com> <20190524182522.GA17299@lonesome.com> <1A31ACF2-746A-49D2-80D5-E80392704B4E@yahoo.com> From: Jason Bacon Message-ID: Date: Fri, 7 Jun 2019 10:42:45 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 517027736D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=PLmBbQSf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::d44 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-3.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; LONG_SUBJ(1.66)[221]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.78)[ip: (1.66), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.30), country: US(-0.06)] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 15:42:48 -0000 On 2019-05-28 18:51, Mark Millard wrote: > > On 2019-May-28, at 14:57, Jason Bacon 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.