From owner-freebsd-ports@freebsd.org Wed Jul 22 09:08:56 2020 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 63FF13775A8 for ; Wed, 22 Jul 2020 09:08:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-21.consmr.mail.gq1.yahoo.com (sonic302-21.consmr.mail.gq1.yahoo.com [98.137.68.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BBV532FYhz3f1p for ; Wed, 22 Jul 2020 09:08:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: erOUhZIVM1nHuW4NNdfl2VnNZ8IGO8ERpoRmj0jTkX1DDPkDftFeKf.8jxDkYvk 92L4typzMwbyiLkPIY5K0.Z9IPoby2enJn6PieLER.d_CDadykOAkI8zvr.903WxXyDkIOKtFW6b FpFxHEjD2sTAbU68LN8FvIB4Q8z6FNf6oB6ydmXeGDKn0d8ZyaiP1OMg_N9ieA_ubVbTWmc2kMus 6uehSLYRpg5x2UxhkoKAqDPEw6FmM6WnLio.ni5ynlsaUcgc2vzGFfjn212cbcvGFhTcvkT25Hnr hRwjVWWI_bzLwmQ46KoIvRLICXqu_bPzbAuHPgoqfmGdPHJIR_kUTefQ.mHhSZ3nxeOGg1r5dEXI 5ityMnj98VlS94gCrNEWX6iJx8A1dqubHvVZPX0aFVGKlFejZkYnnimR_aNb7uoDeJCVBcua2.x2 Cdx0aiIn4dXa6HmBdtw0wfmCONGeeMe2Tj.66XLPIAkwfOOyF7_3wC3X8lOkJEXM6YMMC_2vWhFK Zr64rFMt_VvEXpyj3.2LR8V1eYXDIuw1iykODlg2PisFyaiE8mLbTquVnwQKPQto8Az.gWquyP0C mVodMzHN8aCb15SwfXMvnJRrzUgDqg6R9mKmUUKIVPGoIxjSWM13zkeUn6MJ2dE6pAdEZTKQYnt8 zaPTDCc0S6MEpSDH8G1t67EASD4XXNRdw3RAt4IzpYSII59SidpNZ50aAgeEzuydP11_nfgAyNzJ D_LcVU7zIS.ltGYDi00NwaYfViJsQVaIzvcCl2_89uXevrqfUVxEvTB8r62zoHC8Zzph4hQx36r4 MsYwXBG6SGWIAGE1yzRfp0r_9hxgC9k_mxDH1_pTgPeg9fd9Z4SZ0iHAixlWF4lRZAmQni3gflD7 o4Oi7CSTEC2W.0Ct3C2q1VX434npp0ns323CZzhyxU15ow4lJ0eTNGQEjMF7H7aMaEtWQ6rhahgD o0Vhpjr3Q.6nB.YDPuAzoXRdj9hAiyERr6tf8DTpITCm4as6M.ekbSOMaHc_1fKvtQGVAVzn.Tov yzhOEURWCzRU8.4jhqrwoYXN346Ed2NeiHra1At3QFAGMt1extvh7Ms4b3N_8LtzkTzVbK7WJUKk uwYoYY66ev4i7J8dGGr4Lm3Q2UxXJFfLEvWN2QJSeTnXg0t14GJNyLXmzBzpf31NyOq.03Y70L2A x.ufBRsB5Yel_Inow9AhQgIkHcIvr02XD35682H1R03d4cG1uVTLX8vT85K3rC9yZr9tROU8wpA. rV5XBzbZhb9JsrS_.DwZRpkG71k0V1Aa7JMzgM_C8ed9sv8E701K6ugM1zANN8tpk51i0F9HZEaK vY8XJWShfltbF5ec3n9NR8A6RTlMHmNj3Zgm85S0YCORjyVCe2afqSDrACaFcmgBNkVeUNflH6UR OTxtr8IUwAKDPC.B1VONYM4QptXOS Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Jul 2020 09:08:52 +0000 Received: by smtp423.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 27b9d69dedd2bc8c04fc1b7daf0c0d1e; Wed, 22 Jul 2020 09:08:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Why lang/gcc9 depends native-binutils ? From: Mark Millard In-Reply-To: Date: Wed, 22 Jul 2020 02:08:50 -0700 Cc: FreeBSD ports Content-Transfer-Encoding: quoted-printable Message-Id: <15153DBC-0DE3-4FFB-98F4-7BDDD06E7635@yahoo.com> References: <6B21B9C0-62D5-4ED7-94EE-7715B002F160.ref@yahoo.com> <6B21B9C0-62D5-4ED7-94EE-7715B002F160@yahoo.com> <202007220723.06M7N3qm051026@kx.truefc.org> To: KIRIYAMA Kazuhiko , Bryan Drewery X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4BBV532FYhz3f1p X-Spamd-Bar: - X-Spamd-Result: default: False [-1.93 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.44)[-0.437]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-0.997]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.147:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 09:08:56 -0000 On 2020-Jul-22, at 01:03, Mark Millard wrote: > On 2020-Jul-22, at 00:23, KIRIYAMA Kazuhiko = wrote: >=20 >> Hi, Mark >>=20 >> On Tue, 21 Jul 2020 17:51:41 +0900, >> Mark Millard via freebsd-ports wrote: >>>=20 >>> KIRIYAMA Kazuhiko kiri at truefc.org wrote on >>> Tue Jul 21 02:33:25 UTC 2020 : >>>=20 >>>> checking for iconv declaration...=20 >>>> extern size_t iconv (iconv_t cd, char * *inbuf, size_t = *inbytesleft, char * *outbuf, size_t *outbytesleft); >>>> *** BFD does not support target native-unknown-freebsd13.0. >>>> *** Look in bfd/config.bfd for supported targets. >>>> gmake[3]: *** [Makefile:3563: configure-binutils] Error 1 >>>> gmake[3]: Leaving directory = '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1' >>>> gmake[2]: *** [Makefile:851: all] Error 2 >>>> gmake[2]: Leaving directory = '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1' >>>> =3D=3D=3D> Compilation failed unexpectedly. >>>> Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to >>>> the maintainer. >>>> *** Error code 1 >>>=20 >>> lang/gcc9/Makefile references binutils via: >>>=20 >>> BUILD_DEPENDS+=3D ${LOCALBASE}/bin/as:devel/binutils >>> RUN_DEPENDS+=3D ${LOCALBASE}/bin/as:devel/binutils >>> . . . >>> USE_BINUTILS=3D yes >>>=20 >>> The BUILD_DEPENDS and RUN_DEPENDS references to >>> binutils are to the assembler that binutils >>> generates and installs. So gcc9 needs to be able >>> to use that assembler at both gcc9 build-time and >>> gcc9 run-time. >>>=20 >>> The notation leaves the FLAVOR implicit/empty and >>> so should lead to devel/binutils/Makefile using >>> its line: >>>=20 >>> FLAVOR?=3D native >>>=20 >>> to assign the "native" for its own internal logic >>> to use. >>>=20 >>>=20 >>>=20 >>> Hmm. The "target native-unknown-freebsd13.0" looks >>> very odd to me. The only lines in the devel/binutils >>> Makefile to deal with "unknown-" text directly are: >>>=20 >>> # grep -r unknown- /usr/ports/devel/binutils/ >>> /usr/ports/devel/binutils/Makefile:BUTARGET?=3D = ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL} >>> /usr/ports/devel/binutils/Makefile:BUTARGET=3D = x86_64-unknown-${OPSYS:tl}${OSREL} >>>=20 >>> (I'll later deal with an indirection where "_" is >>> replaced by "-".) >>>=20 >>> Only the 1st line of that pair would potentially form >>> "native-unknown-" text. >>>=20 >>> So looking at the context of the first line I find >>> (". . ." for omitted lines): >>>=20 >>> FLAVOR?=3D native >>> . . . >>> .if ${FLAVOR} !=3D native >>> PKGNAMEPREFIX=3D ${FLAVOR:C/_/-/g}- >>> PLIST=3D ${PKGDIR}/pkg-plist-${FLAVOR:C/_/-/g} >>>=20 >>> .if ${PKGNAMEPREFIX:M*-*-} >>> BUTARGET?=3D ${PKGNAMEPREFIX}${OPSYS:tl}${OSREL} >>> .else >>> BUTARGET?=3D ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL} >>> .endif >>>=20 >>> . . . >>>=20 >>> CONFIGURE_ARGS+=3D --disable-shared \ >>> --target=3D${BUTARGET} >>> .endif >>>=20 >>>=20 >>> (That is also the only instance of "--target=3D" in the >>> Makefile.) >>>=20 >>> The ${FLAVOR} !=3D native test should mean that the code >>> is not used for FLAVOR being exactly "native". >>>=20 >>> There is a separate code block for: >>>=20 >>> .if ${FLAVOR} =3D=3D native >>> BUREMOVE=3D coffdump \ >>> dlltool \ >>> dllwrap \ >>> nlmconv \ >>> srconv \ >>> sysdump \ >>> windmc \ >>> windres >>> USES+=3D localbase >>> CONFIGURE_ARGS+=3D --with-system-zlib \ >>> --with-gmp=3D${LOCALBASE} \ >>> --with-mpfr=3D${LOCALBASE} \ >>> --enable-targets=3Dall \ >>> --enable-threads=3Dyes >>> INFO=3D as \ >>> binutils \ >>> gprof \ >>> bfd \ >>> ld >>> .endif >>>=20 >>> But that code does not specify a specific target >>> (instead: "--enable-targets=3Dall"). >>>=20 >>> There is the FLAVOR value "riscv32_unknown_elf" that >>> could produce target "riscv32-unknown-elf-freebsd13.0" >>> but that is not what was reported as involved. >>>=20 >>> I've ignored CROSS_TOOLCHAIN infrastructure as >>> it was not mentioned as being in use. >>>=20 >>> I do not see how devel/binutils/Makefile would >>> generate "native-unknown-freebsd13.0" text on >>> its own. >>>=20 >>>=20 >>> Sorry I've not been able to identify anything for >>> the error. >>>=20 >>> I'll note that I build ports with poudriere (-devel >>> variant) and have not had the problem in that >>> context. >>>=20 >>=20 >> I forgot to say that make target is `package-recursive'. I >> tried to get PKGNAME with package-depends: >>=20 >>=20 >> root@jdtpkxb:/usr/ports/lang/gcc9 # make -ki package-depends >> gmp-6.2.0:math/gmp >> indexinfo-0.3.1:print/indexinfo >> mpfr-4.0.2:math/mpfr >> mpc-1.1.0_2:math/mpc >> native-binutils-2.33.1_2,1:devel/binutils >> root@jdtpkxb:/usr/ports/lang/gcc9 #=20 >>=20 >>=20 >> But PKGNAME in devel/binutils is: >>=20 >> root@jdtpkxb:/usr/ports/devel/binutils # make -VPKGNAME >> binutils-2.33.1_2,1 >> root@jdtpkxb:/usr/ports/devel/binutils #=20 >>=20 >> I don't know why it is. As far as I see >> devel/binutils/Makefile, FLAVOR default is `native' and >> PKGNAMEPREFIX should be null. >>=20 >> What happens ? >=20 > Hmm. The list from -ki package-depends > is not always specific to one specific > use. For example, on a development machine > where various flavors of binutils have > been built and installed. First I show > the list of various flavors installed: >=20 > # pkg info "*binutils*" > aarch64-binutils-2.33.1_2,1 > aarch64-none-elf-binutils-2.33.1_2,1 > amd64-binutils-2.33.1_2,1 > binutils-2.33.1_2,1 > powerpc-binutils-2.33.1_2,1 > powerpc64-binutils-2.33.1_2,1 >=20 > (If you do the above does one of the lines > of output have "native-" as a prefix?) >=20 > But here is what -ki package-depends > reports for lang/gcc9: >=20 > # cd /usr/ports/lang/gcc9/ > # make -ki package-depends > gmp-6.2.0:math/gmp > indexinfo-0.3.1:print/indexinfo > mpfr-4.1.0:math/mpfr > mpc-1.1.0_2:math/mpc > aarch64-binutils-2.33.1_2,1:devel/binutils > aarch64-none-elf-binutils-2.33.1_2,1:devel/binutils > amd64-binutils-2.33.1_2,1:devel/binutils > binutils-2.33.1_2,1:devel/binutils > powerpc-binutils-2.33.1_2,1:devel/binutils > powerpc64-binutils-2.33.1_2,1:devel/binutils >=20 > Note that I do not get a one prefixed with > "native-" but I get every one of the installed > flavors of binutils is listed, not just one. >=20 > For reference, in my context: >=20 > # make -VPKGNAME > binutils-2.33.1_2,1 >=20 >=20 > What happens if you try: >=20 > # pkg info native-binutils >=20 > ? For reference, my context gets: >=20 > # pkg info native-binutils > pkg: No package(s) matching native-binutils >=20 > # pkg info binutils > binutils-2.33.1_2,1 > Name : binutils > Version : 2.33.1_2,1 > Installed on : Thu Jan 30 01:34:52 2020 PST > Origin : devel/binutils > Architecture : FreeBSD:13:amd64 > Prefix : /usr/local > Categories : devel > Licenses : GPLv3, LGPL3 > Maintainer : bapt@FreeBSD.org > WWW : https://www.gnu.org/software/binutils/ > Comment : GNU binary tools > Options : > NLS : on > RELRO : off > STATIC : off > Shared Libs required: > libintl.so.8 > Annotations : > FreeBSD_version: 1300075 > cpe : = cpe:2.3:a:gnu:binutils:2.33.1:::::freebsd13:x64:2 > flavor : native > repo_type : binary > repository : custom > Flat size : 658MiB > Description : > The GNU Binutils are a collection of binary tools. The main ones are: >=20 > * ld - the GNU linker. > * as - the GNU assembler. >=20 > Most of these programs use BFD, the Binary File Descriptor library, to = do > low-level manipulation. Many of them also use the opcodes library to = assemble > and disassemble machine instructions. >=20 > This port may be used as a replacement for the system binutils and = support > features from the latest versions of GCC. >=20 > For cross-compilation, see the devel/cross-binutils port. >=20 > WWW: https://www.gnu.org/software/binutils/ >=20 I found how to make it produce "native-" prefixed output. Compare: # cd ../../devel/binutils/ # make package-name binutils-2.33.1_2,1 # FLAVOR=3D make package-name native-binutils-2.33.1_2,1 Or in other notation: # make -VPKGNAME binutils-2.33.1_2,1 # FLAVOR=3D make -VPKGNAME native-binutils-2.33.1_2,1 That output is the content of ${PKGNAME} in /usr/ports/Mk/bsd.port.mk in each case. It turns out that when binutils is not installed at all that ${PKGNAME} is used: PACKAGE-DEPENDS-LIST?=3D \ if [ "${CHILD_DEPENDS}" ]; then \ installed=3D$$(${PKG_INFO} -qO ${PKGORIGIN} 2>/dev/null = || \ ${TRUE}); \ if [ "$$installed" ]; then \ break; \ fi; \ if [ -z "$$installed" ]; then \ installed=3D"${PKGNAME}"; \ fi; \ for pkgname in $$installed; do \ ${ECHO_CMD} "$$pkgname ${.CURDIR} ${PKGORIGIN}"; = \ done; \ fi; \ . . . This explains why I've not seen "native-" when doing the types of commands you are doing: I have binutils installed (multiple flavors, in fact). As to how FLAVOR=3D ends up defined but empty: there is the recursive use of package-depends-list in the code hidden by the ". . ." above: checked=3D"${PARENT_CHECKED}"; \ for dir in ${_LIB_RUN_DEPENDS:C,[^:]*:([^:]*):?.*,\1,}; do \ unset flavor; \ case $${dir} in \ *@*) \ flavor=3D$${dir\#*@}; \ dir=3D$${dir%@*}; \ ;; \ esac; \ case "$$dir" in \ /*) ;; \ *) dir=3D${PORTSDIR}/$$dir ;; \ esac ; \ dir=3D$$(${REALPATH} $$dir); \ if [ -d $$dir ]; then \ case $$checked in \ $$dir|$$dir\ *|*\ $$dir|*\ $$dir\ *) continue;; = \ esac; \ childout=3D$$(cd $$dir; ${SETENV} = FLAVOR=3D$${flavor} ${MAKE} CHILD_DEPENDS=3Dyes = PARENT_CHECKED=3D"$$checked" package-depends-list); \ set -- $$childout; \ childdir=3D""; \ while [ $$\# !=3D 0 ]; do \ childdir=3D"$$childdir $$2"; \ ${ECHO_CMD} "$$1 $$2 $$3"; \ shift 3; \ done; \ checked=3D"$$dir $$childdir $$checked"; \ else \ ${ECHO_MSG} "${PKGNAME}: \"$$dir\" non-existent = -- dependency list incomplete" >&2; \ fi; \ done The FLAVOR=3D$${flavor} can have flavor unset and so produce FLAVOR=3D in the recursion. That in turn gets the "native-" prefix involved. The oddity of the "native-" prefix showing up may be a problem for Bryan Drewery or someone like that to address. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)