Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jul 2020 02:08:50 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        KIRIYAMA Kazuhiko <kiri@truefc.org>, Bryan Drewery <bdrewery@FreeBSD.org>
Cc:        FreeBSD ports <freebsd-ports@freebsd.org>
Subject:   Re: Why lang/gcc9 depends  native-binutils ?
Message-ID:  <15153DBC-0DE3-4FFB-98F4-7BDDD06E7635@yahoo.com>
In-Reply-To: <E43D802B-016C-40E3-97FB-D6E31FB8800E@yahoo.com>
References:  <6B21B9C0-62D5-4ED7-94EE-7715B002F160.ref@yahoo.com> <6B21B9C0-62D5-4ED7-94EE-7715B002F160@yahoo.com> <202007220723.06M7N3qm051026@kx.truefc.org> <E43D802B-016C-40E3-97FB-D6E31FB8800E@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jul-22, at 01:03, Mark Millard <marklmi at yahoo.com> wrote:

> On 2020-Jul-22, at 00:23, KIRIYAMA Kazuhiko <kiri at truefc.org> =
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)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15153DBC-0DE3-4FFB-98F4-7BDDD06E7635>