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:
>
>> Hi, Mark
>>
>> On Tue, 21 Jul 2020 17:51:41 +0900,
>> Mark Millard via freebsd-ports wrote:
>>>
>>> KIRIYAMA Kazuhiko kiri at truefc.org wrote on
>>> Tue Jul 21 02:33:25 UTC 2020 :
>>>
>>>> checking for iconv declaration...
>>>> 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'
>>>> ===> Compilation failed unexpectedly.
>>>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
>>>> the maintainer.
>>>> *** Error code 1
>>>
>>> lang/gcc9/Makefile references binutils via:
>>>
>>> BUILD_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils
>>> RUN_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils
>>> . . .
>>> USE_BINUTILS= yes
>>>
>>> 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.
>>>
>>> The notation leaves the FLAVOR implicit/empty and
>>> so should lead to devel/binutils/Makefile using
>>> its line:
>>>
>>> FLAVOR?= native
>>>
>>> to assign the "native" for its own internal logic
>>> to use.
>>>
>>>
>>>
>>> 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:
>>>
>>> # grep -r unknown- /usr/ports/devel/binutils/
>>> /usr/ports/devel/binutils/Makefile:BUTARGET?=
>>> ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
>>> /usr/ports/devel/binutils/Makefile:BUTARGET=
>>> x86_64-unknown-${OPSYS:tl}${OSREL}
>>>
>>> (I'll later deal with an indirection where "_" is
>>> replaced by "-".)
>>>
>>> Only the 1st line of that pair would potentially form
>>> "native-unknown-" text.
>>>
>>> So looking at the context of the first line I find
>>> (". . ." for omitted lines):
>>>
>>> FLAVOR?= native
>>> . . .
>>> .if ${FLAVOR} != native
>>> PKGNAMEPREFIX= ${FLAVOR:C/_/-/g}-
>>> PLIST= ${PKGDIR}/pkg-plist-${FLAVOR:C/_/-/g}
>>>
>>> .if ${PKGNAMEPREFIX:M*-*-}
>>> BUTARGET?= ${PKGNAMEPREFIX}${OPSYS:tl}${OSREL}
>>> .else
>>> BUTARGET?= ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
>>> .endif
>>>
>>> . . .
>>>
>>> CONFIGURE_ARGS+= --disable-shared \
>>> --target=${BUTARGET}
>>> .endif
>>>
>>>
>>> (That is also the only instance of "--target=" in the
>>> Makefile.)
>>>
>>> The ${FLAVOR} != native test should mean that the code
>>> is not used for FLAVOR being exactly "native".
>>>
>>> There is a separate code block for:
>>>
>>> .if ${FLAVOR} == native
>>> BUREMOVE= coffdump \
>>> dlltool \
>>> dllwrap \
>>> nlmconv \
>>> srconv \
>>> sysdump \
>>> windmc \
>>> windres
>>> USES+= localbase
>>> CONFIGURE_ARGS+= --with-system-zlib \
>>> --with-gmp=${LOCALBASE} \
>>> --with-mpfr=${LOCALBASE} \
>>> --enable-targets=all \
>>> --enable-threads=yes
>>> INFO= as \
>>> binutils \
>>> gprof \
>>> bfd \
>>> ld
>>> .endif
>>>
>>> But that code does not specify a specific target
>>> (instead: "--enable-targets=all").
>>>
>>> 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.
>>>
>>> I've ignored CROSS_TOOLCHAIN infrastructure as
>>> it was not mentioned as being in use.
>>>
>>> I do not see how devel/binutils/Makefile would
>>> generate "native-unknown-freebsd13.0" text on
>>> its own.
>>>
>>>
>>> Sorry I've not been able to identify anything for
>>> the error.
>>>
>>> I'll note that I build ports with poudriere (-devel
>>> variant) and have not had the problem in that
>>> context.
>>>
>>
>> I forgot to say that make target is `package-recursive'. I
>> tried to get PKGNAME with package-depends:
>>
>>
>> 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 #
>>
>>
>> But PKGNAME in devel/binutils is:
>>
>> root@jdtpkxb:/usr/ports/devel/binutils # make -VPKGNAME
>> binutils-2.33.1_2,1
>> root@jdtpkxb:/usr/ports/devel/binutils #
>>
>> I don't know why it is. As far as I see
>> devel/binutils/Makefile, FLAVOR default is `native' and
>> PKGNAMEPREFIX should be null.
>>
>> What happens ?
>
> 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:
>
> # 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
>
> (If you do the above does one of the lines
> of output have "native-" as a prefix?)
>
> But here is what -ki package-depends
> reports for lang/gcc9:
>
> # 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
>
> 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.
>
> For reference, in my context:
>
> # make -VPKGNAME
> binutils-2.33.1_2,1
>
>
> What happens if you try:
>
> # pkg info native-binutils
>
> ? For reference, my context gets:
>
> # pkg info native-binutils
> pkg: No package(s) matching native-binutils
>
> # 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 : b...@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:
>
> * ld - the GNU linker.
> * as - the GNU assembler.
>
> 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.
>
> This port may be used as a replacement for the system binutils and support
> features from the latest versions of GCC.
>
> For cross-compilation, see the devel/cross-binutils port.
>
> WWW: https://www.gnu.org/software/binutils/
>
I found how to make it produce "native-"
prefixed output. Compare:
# cd ../../devel/binutils/
# make package-name
binutils-2.33.1_2,1
# FLAVOR= make package-name
native-binutils-2.33.1_2,1
Or in other notation:
# make -VPKGNAME
binutils-2.33.1_2,1
# FLAVOR= 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?= \
if [ "${CHILD_DEPENDS}" ]; then \
installed=$$(${PKG_INFO} -qO ${PKGORIGIN} 2>/dev/null || \
${TRUE}); \
if [ "$$installed" ]; then \
break; \
fi; \
if [ -z "$$installed" ]; then \
installed="${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= ends up defined but empty: there
is the recursive use of package-depends-list in the
code hidden by the ". . ." above:
checked="${PARENT_CHECKED}"; \
for dir in ${_LIB_RUN_DEPENDS:C,[^:]*:([^:]*):?.*,\1,}; do \
unset flavor; \
case $${dir} in \
*@*) \
flavor=$${dir\#*@}; \
dir=$${dir%@*}; \
;; \
esac; \
case "$$dir" in \
/*) ;; \
*) dir=${PORTSDIR}/$$dir ;; \
esac ; \
dir=$$(${REALPATH} $$dir); \
if [ -d $$dir ]; then \
case $$checked in \
$$dir|$$dir\ *|*\ $$dir|*\ $$dir\ *) continue;; \
esac; \
childout=$$(cd $$dir; ${SETENV} FLAVOR=$${flavor}
${MAKE} CHILD_DEPENDS=yes PARENT_CHECKED="$$checked" package-depends-list); \
set -- $$childout; \
childdir=""; \
while [ $$\# != 0 ]; do \
childdir="$$childdir $$2"; \
${ECHO_CMD} "$$1 $$2 $$3"; \
shift 3; \
done; \
checked="$$dir $$childdir $$checked"; \
else \
${ECHO_MSG} "${PKGNAME}: \"$$dir\" non-existent --
dependency list incomplete" >&2; \
fi; \
done
The FLAVOR=$${flavor} can have flavor unset and so
produce FLAVOR= 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.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
