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.


===
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"

Reply via email to