Bug 224217 - [patch] Fix cross build of base/ ports
Summary: [patch] Fix cross build of base/ ports
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Port Management Team
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2017-12-09 22:56 UTC by Nathan Whitehorn
Modified: 2018-02-18 21:17 UTC (History)
9 users (show)

See Also:


Attachments
Fixes (22.09 KB, patch)
2017-12-09 22:56 UTC, Nathan Whitehorn
no flags Details | Diff
updated patch that fixes fetch and package name (17.92 KB, patch)
2018-01-31 18:00 UTC, Steve Wills
no flags Details | Diff
Updated patch (35.74 KB, patch)
2018-02-01 17:55 UTC, Steve Wills
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Whitehorn freebsd_committer 2017-12-09 22:56:42 UTC
Created attachment 188675 [details]
Fixes

The attached patch fixes the build of the base/ ports and ports-mgmt/pkg via cross-build on systems without QEMU userland support.

It does the following:
- Set C*_FOR_BUILD variables that various GNU tools need for their native compiler in autoconf.
- Set CPPFLAGS to include the sysroot flags so that code using the preprocessor by itself also gets the right headers. This fixes GCC's autoconf checks that override autoconf's AC_GET_HEADER macros to use cpp directly rather than the compiler.
- Have a cross-built pkg(8) use the native system pkg to package itself rather than the new cross-built pkg, which of course is not executable.
- Upgrade GCC to 6.3 from 5.4
- Change the vendor tag on base/gcc from portbld to unknown to fix some brokenness in its internal build system and match the cross-compiler installed by e.g. powerpc64-gcc.
- Repair GCC's build system to pass CPPFLAGS around correctly and avoid conflation of host and build CPPFLAGS, which we require as a result of GCC's broken non-inclusion of -isystem =/usr/include by default unless a cross root is present when building the cross-compiler.
- Repair GCC's build system to set proper C*FLAGS for native tool builds.
Comment 1 Alexander Kabaev freebsd_committer 2017-12-20 13:50:15 UTC
This look sane, will take a closer look at GCC changes on weekend.
Comment 2 Andreas Tobler freebsd_committer 2017-12-20 21:25:17 UTC
Bump gcc at least to 6.4, 6.3 is already EOL.
Comment 3 Alexander Kabaev freebsd_committer 2017-12-24 00:09:03 UTC
I'll update to 6.4 this week
Comment 4 Mark Millard 2018-01-13 23:05:51 UTC
FYI: There are also bugzilla reports:

214400,214401,214402,214403,214404,214405

for base/gcc and base/binutils . Some or all
may be addressed here. These are from back
when I tried to use it and recorded the
work arounds that I used to get the next
stage as I went along.
Comment 5 Nathan Whitehorn freebsd_committer 2018-01-22 23:38:57 UTC
(In reply to Alexander Kabaev from comment #3)

Did you want me to do the update? I was trying to keep this in sync with devel/powerpc64-gcc, which is still 6.3.
Comment 6 Steve Wills freebsd_committer 2018-01-31 18:00:13 UTC
Created attachment 190229 [details]
updated patch that fixes fetch and package name

Here's an updated version that fixes the fetch and package name in base/gcc
Comment 7 Steve Wills freebsd_committer 2018-01-31 18:54:15 UTC
When trying to build world after installing the new packages, I find I have to set COMPILER_TYPE manually and also hit this error:

cc -isystem /usr/obj/usr/src/powerpc.powerpc64/tmp/usr/include -L/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/lib -B/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/lib --sysroot=/usr/obj/usr/src/powerpc.powerpc64/tmp -B/usr/obj/usr/src/powerpc.powerpc64/tmp/usr/bin -shared -nostdlib hack.c -o hack.pico
collect2: fatal error: cannot find 'ld'
Comment 8 Steve Wills freebsd_committer 2018-01-31 18:54:43 UTC
(In reply to Steve Wills from comment #7)
Sorry, was building kernel and world, that failure was during kernel build.
Comment 9 Mark Millard 2018-01-31 19:07:40 UTC
(In reply to Steve Wills from comment #7)

See bugzilla 214404 for a prior report of such
"collect2: fatal error: cannot find 'ld'" notices.

Although it has been some time, I submitted:

214400,214401,214402,214403,214404,214405

back when I tried the base/ materials. I do not
know how much has been addressed after that.
Comment 10 Steve Wills freebsd_committer 2018-02-01 02:06:40 UTC
(In reply to Mark Millard from comment #9)
I have found a way to get it to at least find ld, now it just needs some other help, I'll keep at it and post patches when I have it working.
Comment 11 Steve Wills freebsd_committer 2018-02-01 17:55:40 UTC
Created attachment 190251 [details]
Updated patch

Here's an updated patch which for me allows the built compiler to generate binaries if I pass -sysroot and -isystem. The OSREL has to be in the --target due to this change:

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config.gcc?r1=222192&r2=222191&pathrev=222192

that was introduced due to this bug report:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535

When the --target and --host don't match, gcc's configure decides you're building a cross compiler, which we aren't doing here. So unfortunately it seems like the right thing to do is make --target and --host match and to have the OSREL in both for both gcc and binutils.

This change does that and after updating and rebuilding everything I seem to have a working compiler.

Please test and see if this fixes the issues reported in this bug and the other bugs mentioned.
Comment 12 Steve Wills freebsd_committer 2018-02-01 18:12:09 UTC
(In reply to Steve Wills from comment #11)
Correction, passing -sysroot and -isystem is not necessary.
Comment 13 Mark Millard 2018-02-02 05:22:14 UTC
(In reply to Steve Wills from comment #11)

I'm not sure if I'll be able to set up and
test for my old reports this weekend or not.
My time with FreeBSD systems has started to
be greatly constrained in recent times.

If I manage to test, I'll report the results.
Comment 14 Mark Millard 2018-02-03 20:46:57 UTC
(In reply to Steve Wills from comment #12)

Context:

# uname -apKU
FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT  r327485M  amd64 amd64 1200054 1200054

with cross build attempted for targeting powerpc64.

base/binutils did not build once I got needed tools in place.
This stage is tied to the README's:

4/ build the required port
$ cd base/binutils
make CROSS_TOOLCHAIN=sparc64-gcc CROSS_SYSROOT=/sysroots/sparc64 package

(but with powerpc64-gcc and my cross-sysroot path).


Summary of failures:

I had to install devel/bison and devel/gmake to even get
started. devel/powerpc64-xtoolchain-gcc is insufficient.
(I had it installed already.)

It then looked for powerpc64-unknown-freebsd12.0-ar but
no such exists. Instead there is:

/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ar

which is from:

# pkg which /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ar
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ar was installed by package powerpc64-gcc-6.3.0


With that I stopped instead of providing a workaround
this time.


Detail steps/sequence for as far as I got:

I used a pre-existing installworld :

/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/

from having built with the system clang and devel/powerpc64-binutils
instead of with gcc 4.2.1 . (I normally experiment with clang
based targeting for powerpc64 and powerpc.)

I reverted /usr/ports/base and then applied the patch. So:

# svnlite status /usr/ports/base | sort
M       /usr/ports/base/gcc/Makefile
M       /usr/ports/base/gcc/distinfo
M       /usr/ports/base/gcc/pkg-plist

became:

# svnlite status /usr/ports/base/
M       /usr/ports/base/binutils/Makefile
M       /usr/ports/base/gcc/Makefile
M       /usr/ports/base/gcc/distinfo
?       /usr/ports/base/gcc/files/patch-Makefile.in
?       /usr/ports/base/gcc/files/patch-gcc-Makefile.in
?       /usr/ports/base/gcc/files/patch-gcc-configure
M       /usr/ports/base/gcc/pkg-plist

For reference:

# pkg info "powerpc64*"
powerpc64-binutils-2.29.1,1
powerpc64-gcc-6.3.0
powerpc64-xtoolchain-gcc-0.2

I then:

# make CROSS_TOOLCHAIN=powerpc64-gcc CROSS_SYSROOT=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils package

I left RELRO and STATIC unchecked.

The result was:

===>  License GPLv3 LGPL3 accepted by the user
===>   freebsd-binutils-2.29.1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by freebsd-binutils-2.29.1 for building
===>  Extracting for freebsd-binutils-2.29.1
=> SHA256 Checksum OK for binutils-2.29.1.tar.bz2.
===>  Patching for freebsd-binutils-2.29.1
===>  Applying FreeBSD patches for freebsd-binutils-2.29.1
/usr/bin/sed -i.bak -e "s/-ldl//g" /wrkdirs/usr/ports/base/binutils/work/binutils-2.29.1/gold/testsuite/Makefile.in
===>   freebsd-binutils-2.29.1 depends on executable: bison - not found
===>   freebsd-binutils-2.29.1 depends on executable: bison - not found
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/base/binutils
*** Error code 1

Stop.
make: stopped in /usr/ports/base/binutils

Nothing in the README indicated to have bison ready first.

So. . .

# pkg install bison

Trying again. . .

Similar sequence for gmake:

# pkg install gmake

Finally . . .

# make CROSS_TOOLCHAIN=powerpc64-gcc CROSS_SYSROOT=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils package
===>   freebsd-binutils-2.29.1 depends on executable: bison - found
===>   freebsd-binutils-2.29.1 depends on executable: gmake - found
===>  Configuring for freebsd-binutils-2.29.1
configure: loading site script /usr/ports/Templates/config.site
. . .
checking for insque... yes
checking for memchr... rm -f libz.a
powerpc64-unknown-freebsd12.0-ar cru libz.a libz_a-adler32.o libz_a-compress.o libz_a-crc32.o libz_a-deflate.o libz_a-gzread.o libz_a-gzclose.o libz_a-gzwrite.o libz_a-gzlib.o libz_a-infback.o libz_a-inffast.o libz_a-inflate.o libz_a-inftrees.o libz_a-trees.o libz_a-uncompr.o libz_a-zutil.o 
gmake[4]: powerpc64-unknown-freebsd12.0-ar: Command not found
gmake[4]: *** [Makefile:401: libz.a] Error 127
gmake[4]: Leaving directory '/wrkdirs/usr/ports/base/binutils/work/binutils-2.29.1/zlib'
gmake[3]: *** [Makefile:9026: all-zlib] Error 2
gmake[3]: *** Waiting for unfinished jobs....
yes
. . .

Using Make_JOBS_UNSAFE:

# make MAKE_JOBS_UNSAFE=yes CROSS_TOOLCHAIN=powerpc64-gcc CROSS_SYSROOT=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils package
. . .
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -c -DHAVE_CONFIG_H -O2 -pipe  --sysroot=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils -isystem /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/usr/include --sysroot=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils -isystem /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/usr/include -g -fstack-protector -fno-strict-aliasing --sysroot=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils -isystem /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/usr/include --sysroot=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils -isystem /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/usr/include -I. -I./../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -D_GNU_SOURCE ./strverscmp.c -o strverscmp.o
rm -f ./libiberty.a pic/./libiberty.a noasan/./libiberty.a
powerpc64-unknown-freebsd12.0-ar rc ./libiberty.a \
  ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./d-demangle.o ./dwarfnames.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./vprintf-support.o ./rust-demangle.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./simple-object-xcoff.o ./sort.o ./spaces.o ./splay-tree.o ./stack-limit.o ./strerror.o ./strsignal.o ./timeval-utils.o ./unlink-if-ordinary.o ./xasprintf.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./xvasprintf.o  ./mempcpy.o ./strverscmp.o
gmake[4]: powerpc64-unknown-freebsd12.0-ar: Command not found
gmake[4]: *** [Makefile:250: libiberty.a] Error 127
gmake[4]: Leaving directory '/wrkdirs/usr/ports/base/binutils/work/binutils-2.29.1/libiberty'
gmake[3]: *** [Makefile:8013: all-libiberty] Error 2
gmake[3]: Leaving directory '/wrkdirs/usr/ports/base/binutils/work/binutils-2.29.1'
gmake[2]: *** [Makefile:849: all] Error 2
gmake[2]: Leaving directory '/wrkdirs/usr/ports/base/binutils/work/binutils-2.29.1'
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/base/binutils
*** Error code 1

Stop.
make: stopped in /usr/ports/base/binutils


# find /usr/local/bin/ -name "*powerpc64*-ar*" -print
/usr/local/bin/powerpc64-freebsd-ar
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ar


I've not done any work arounds to get farther into the
sequence to get other evidence for how things would go.
Comment 15 Mark Millard 2018-02-03 21:34:20 UTC
(In reply to Mark Millard from comment #14)

I forgot to list the /usr/ports/ version
information:

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 460760
Last Changed Rev: 460760
Comment 16 Mark Millard 2018-02-04 01:35:41 UTC
(In reply to Steve Wills from comment #12)

No go for base/gcc either. . .

I got some more time and attempted base/gcc despite
the base/binutils failure (comments #14 and #15):

# make CROSS_TOOLCHAIN=powerpc64-gcc CROSS_SYSROOT=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils package

It retrieved many things not installed in order to build:

. . .
===>  Extracting for freebsd-gcc-6.3.0
=> SHA256 Checksum OK for gcc-6.3.0.tar.bz2.
=> SHA256 Checksum OK for mpfr-3.1.6.tar.xz.
=> SHA256 Checksum OK for gmp-6.1.2.tar.xz.
=> SHA256 Checksum OK for mpc-1.0.3.tar.gz.
. . .
===>   freebsd-gcc-6.3.0 depends on executable: makeinfo - not found
. . .
=> SHA256 Checksum OK for texinfo/6.5/texinfo-6.5.tar.xz.
=> SHA256 Checksum OK for texinfo/6.5/htmlxref.cnf.
=> SHA256 Checksum OK for texinfo/6.5/texi2dvi.
=> SHA256 Checksum OK for texinfo/6.5/texinfo.tex.
. . .
===>   texinfo-6.5,1 depends on executable: help2man - not found
. . .
=> SHA256 Checksum OK for help2man-1.47.5.tar.xz.
. . .
===>   help2man-1.47.5 depends on package: p5-Locale-gettext>=0 - not found
. . .
=> SHA256 Checksum OK for gettext-1.07.tar.gz.
. . .
===>   p5-Locale-gettext-1.07 depends on executable: msgfmt - not found
. . .
=> SHA256 Checksum OK for gettext-0.19.8.1.tar.xz.
. . .

It did find a couple of things (besides pkg):

===>   gettext-tools-0.19.8.1 depends on package: libiconv>=1.14_11 - found
===>   gettext-tools-0.19.8.1 depends on shared library: libintl.so - found  (/usr/local/lib/libintl.so)

[NOTE: that /usr/local/lib/libintl.so path vs. the later
/wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/intl/.libs/libintl.so path.]


It failed building devel/gettext-tools with:

/wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/intl/.libs/libintl.so: undefined reference to `pthread_create'



Details:

--- recode-sr-latin ---
libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -O2 -pipe --sysroot=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils -isystem /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/usr/include -DLIBICONV_PLUG -g -fstack-protector -fno-strict-aliasing --sysroot=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils -fstack-protector -o .libs/recode-sr-latin recode_sr_latin-recode-sr-latin.o recode_sr_latin-filter-sr-latin.o  ../gnulib-lib/.libs/libgettextlib.so /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/intl/.libs/libintl.so -L/usr/local/lib ../intl/.libs/libintl.so -lm -lncurses -Wl,-rpath -Wl,/usr/local/lib
. . .
--- recode-sr-latin ---
/wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/intl/.libs/libintl.so: undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
*** [recode-sr-latin] Error code 1

make[11]: stopped in /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/src
--- hostname ---
/wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/intl/.libs/libintl.so: undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
*** [hostname] Error code 1

make[11]: stopped in /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/src
--- urlget ---
/wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/intl/.libs/libintl.so: undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
*** [urlget] Error code 1

make[11]: stopped in /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/src
Comment 17 Mark Millard 2018-02-04 02:07:40 UTC
(In reply to Mark Millard from comment #16)

Looks like I should have noted that I already had
a perl in place:

checking for perl... /usr/local/bin/perl

This might go along with devel/bison and devel/gmake
as possibly required --but possibly not automatically
built if missing.

I should have shown that hostname and urlget also got the
pthread_create notice:

--- hostname ---
/wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/intl/.libs/libintl.so: undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
*** [hostname] Error code 1

make[11]: stopped in /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/src
--- urlget ---
/wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/intl/.libs/libintl.so: undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
*** [urlget] Error code 1

make[11]: stopped in /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.19.8.1/gettext-tools/src



One odd thing that I saw in the output was:
(note the "Unable to load interpreter" and
the long command text but still getting a yes)

checking whether the C++ compiler (/usr/local/bin/powerpc64-unknown-freebsd12.0-g++ -O2 -pipe --sysroot=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils -isystem /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/usr/include -DLIBICONV_PLUG -g -fstack-protector -fno-strict-aliasing  --sysroot=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils -isystem /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/usr/include -isystem /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/usr/include/c++/v1 -nostdinc++ -DLIBICONV_PLUG  --sysroot=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils -fstack-protector) works... Unable to load interpreter
yes

But its later "checking" that referenced
/usr/local/bin/powerpc64-unknown-freebsd12.0-g++
seemed to go okay.


Note: /wrkdirs is from my /etc/make.conf having:

WRKDIRPREFIX?=/wrkdirs
Comment 18 Mark Millard 2018-02-05 23:32:19 UTC
(In reply to Mark Millard from comment #17)

My results may have been skewed by my forgetting to
revert some forced -unknown- usage in BUTARGET
and BU_PREFIX in the likes of devel/binutils/Makefile
and devel/powerpc64-gcc/Makefile and in
CROSS_BINUTILS_PREFIX in
devel/powerpc64-xtoolchain-gcc/files/xtoolchain.mk.in .

I think this was from my earlier attempt at experimenting
with base/binutils and base/gcc .

For reference I had:

# svnlite diff /usr/ports/devel/binutils/Makefile
Index: /usr/ports/devel/binutils/Makefile
===================================================================
--- /usr/ports/devel/binutils/Makefile	(revision 460973)
+++ /usr/ports/devel/binutils/Makefile	(working copy)
@@ -36,7 +36,7 @@
 GNU_CONFIGURE=	yes
 
 .if defined(PKGNAMEPREFIX)
-BUTARGET?=	${PKGNAMEPREFIX}${OPSYS:tl}
+BUTARGET?=	${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
 OPTIONS_EXCLUDE=	NLS
 INFO_PATH=	${PKGNAMEPREFIX:S/-$//}/info
 CONFIGURE_ARGS+=	--disable-shared \

# svnlite diff /usr/ports/devel/powerpc64-gcc/Makefile
Index: /usr/ports/devel/powerpc64-gcc/Makefile
===================================================================
--- /usr/ports/devel/powerpc64-gcc/Makefile	(revision 460973)
+++ /usr/ports/devel/powerpc64-gcc/Makefile	(working copy)
@@ -29,7 +29,7 @@
 .if empty(GCC_TARGET)
 # We are building for a FreeBSD target
 GCC_TARGET?=	${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
-BU_PREFIX?=	${PKGNAMEPREFIX}${OPSYS:tl}
+BU_PREFIX?=	${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
 EXTRA_PATCHES+= ${FILESDIR}/freebsd-format-extensions
 .else
 BU_PREFIX?=	${GCC_TARGET}

# svnlite diff /usr/ports/devel/powerpc64-xtoolchain-gcc/Makefile
Index: /usr/ports/devel/powerpc64-xtoolchain-gcc/Makefile
===================================================================
--- /usr/ports/devel/powerpc64-xtoolchain-gcc/Makefile	(revision 460973)
+++ /usr/ports/devel/powerpc64-xtoolchain-gcc/Makefile	(working copy)
@@ -1,7 +1,7 @@
 # $FreeBSD$
 
 PORTNAME=	xtoolchain
-PORTVERSION=	0.2
+PORTVERSION=	0.3
 CATEGORIES=	devel
 MASTER_SITES=	# none
 DISTFILES=	# none
@@ -28,6 +28,7 @@
 SUB_FILES=	xtoolchain.mk
 SUB_LIST=	TARGETARCH=${TOOLCHAIN_PREFIX:C/-//g} \
 		OPSYS=${OPSYS:tl} \
+		OSREL=${OSREL} \
 		XCC=${XCC} \
 		XCXX=${XCXX} \
 		XCPP=${XCPP} \

# svnlite diff /usr/ports/devel/powerpc64-xtoolchain-gcc/files/xtoolchain.mk.in
Index: /usr/ports/devel/powerpc64-xtoolchain-gcc/files/xtoolchain.mk.in
===================================================================
--- /usr/ports/devel/powerpc64-xtoolchain-gcc/files/xtoolchain.mk.in	(revision 460973)
+++ /usr/ports/devel/powerpc64-xtoolchain-gcc/files/xtoolchain.mk.in	(working copy)
@@ -1,5 +1,5 @@
 XCC=%%LOCALBASE%%/bin/%%XCC%%
 XCXX=%%LOCALBASE%%/bin/%%XCXX%%
 XCPP=%%LOCALBASE%%/bin/%%XCPP%%
-CROSS_BINUTILS_PREFIX=%%LOCALBASE%%/%%TARGETARCH%%-%%OPSYS%%/bin/
+CROSS_BINUTILS_PREFIX=%%LOCALBASE%%/%%TARGETARCH%%-unknown-%%OPSYS%%%%OSREL%%/bin/
 X_COMPILER_TYPE=%%X_COMPILER_TYPE%%
Comment 19 commit-hook freebsd_committer 2018-02-06 14:13:52 UTC
A commit references this bug:

Author: swills
Date: Tue Feb  6 14:13:35 UTC 2018
New revision: 461053
URL: https://svnweb.freebsd.org/changeset/ports/461053

Log:
  Don't use pkg-static when cross building

  PR:		224217
  Submitted by:	nwhitehorn
  Approved by:	bapt

Changes:
  head/ports-mgmt/pkg/Makefile
  head/ports-mgmt/pkg-devel/Makefile
Comment 20 commit-hook freebsd_committer 2018-02-06 14:33:11 UTC
A commit references this bug:

Author: swills
Date: Tue Feb  6 14:32:53 UTC 2018
New revision: 461058
URL: https://svnweb.freebsd.org/changeset/ports/461058

Log:
  Fix cross build of base/ ports

  This is a follow up to r461057 and fixes base/binutils and base/gcc in my
  testing.

  PR:		224217
  Submitted by:	nwhitehorn (partially, I made additional changes)
  Reviewed by:	bapt

Changes:
  head/Mk/bsd.port.mk
  head/base/binutils/Makefile
  head/base/binutils/pkg-plist.powerpc64
  head/base/gcc/Makefile
  head/devel/binutils/Makefile
  head/devel/powerpc64-binutils/pkg-plist
  head/devel/powerpc64-gcc/Makefile
  head/devel/powerpc64-xtoolchain-gcc/Makefile
  head/devel/powerpc64-xtoolchain-gcc/files/xtoolchain.mk.in
Comment 21 Steve Wills freebsd_committer 2018-02-06 14:34:28 UTC
Committed, thanks! Let me know if you run into any other issues.
Comment 22 commit-hook freebsd_committer 2018-02-06 14:39:19 UTC
A commit references this bug:

Author: swills
Date: Tue Feb  6 14:38:28 UTC 2018
New revision: 461059
URL: https://svnweb.freebsd.org/changeset/ports/461059

Log:
  Add files missed in previous commit

  PR:		224217
  Submitted by:	nwhitehorn

Changes:
  head/base/gcc/files/patch-Makefile.in
  head/base/gcc/files/patch-gcc-Makefile.in
  head/base/gcc/files/patch-gcc-configure
Comment 23 Mark Millard 2018-02-07 07:34:13 UTC
(In reply to commit-hook from comment #22)

[I got some time to try it: lack of sleep.]

This update worked for me after installing the
following via pkg from my normal poudriere-devel
runs. The README's make commands failed to build
some if they were all missing at the time,
although it tried.

print/texinfo
misc/help2man
devel/p5-Locale-gettext
devel/gettext-tools

(much like devel/bison and devel/gmake and
lang/perl5.24 were installed first in order
for base/binutils to build). Normal
poudriere-devel builds of these all went fine.


/usr/ports/base/README still makes no mention
of these 7 ports being needed, just mentioning
(for an example *):

pkg install *-xtoolchain-gcc

(in 1/).

Note: I've not done the pkg-plist step or actually
installed what is built.
Comment 24 Gerald Pfeifer freebsd_committer 2018-02-11 23:05:33 UTC
(In reply to Nathan Whitehorn from comment #0)
> [...]

Is there anything in this patchset that should be submitted upstream
(for GCC 8)?
Comment 25 Nathan Whitehorn freebsd_committer 2018-02-11 23:14:21 UTC
(In reply to Gerald Pfeifer from comment #24)

Probably all the internal GCC build stuff. It would also be *really* nice if we didn't need all the -isystem nonsense when building and the cross-compiler had -I =/usr/include by default when built without a sysroot.
Comment 26 Mark Millard 2018-02-17 21:58:19 UTC
(In reply to Mark Millard from comment #23)

Turns out that a modern devel/powerpc64-binutils
uses powerpc64-unknown-freebsd12.0- prefixes,
just like base/binutils does. The same goes
for devel/powerpc64-gcc and base/gcc .

So base/binutils and devel/powerpc64-binutils
end up with PATH controlling which directory
is used when the path is implicit, just like
base/gcc vs. devel/powerpc64-gcc does.

The above is stated for a powerpc64 context
with both a base/{binutils,gcc} pair installed
and a devel/powerpc64-{binutils,gcc} pair built
and installed. /usr/bin/ vs. /usr/local/bin/
and the like being involved for PATH use when
not explicit.

(I need to be careful of this once I get to the
point of testing base/{binutils,gcc} use in my
powerpc64 context. I normally have
devel/powerpc64-{binutils,gcc} installed and so
could implicitly use the wrong files.)
Comment 27 Mark Millard 2018-02-17 23:36:34 UTC
(In reply to commit-hook from comment #22)

base/binutils/pkg-plist.sparc64 and
base/binutils/pkg-plist.powerpc64 list:

bin/as
bin/ld
bin/ld.bfd
bin/objcopy
bin/objdump

This appears to imply that the README's sparc64 example lines:

2/ cross build world
make CROSS_TOOLCHAIN=sparc64-gcc TARGET=sparc64 TARGET_ARCH=sparc64 buildworld

are intended to be based on (implicitly or
explicitly) WITHOUT_BINUTILS= so that the
files listed are only from base/binutils .
This is likely because the system binutils
are insufficient in some cases for the likes
of, at least, powerpc64.

WITHOUT_BINUTILS= is the default only for arm64/aarch64,
riscv/riscv64, and riscv/riscv64sf according to the
man src.conf that I'm reading.

(It turns out my normal/historical cross-builds include
the system binutils by not having been explicit to avoid
such, both for system-clang based builds and for
powerpc64-xtoolchain-gcc based builds: Not the best way
to test base/binutils use. My test target-context here is:
powerpc64.)
Comment 28 Mark Millard 2018-02-18 21:17:58 UTC
(In reply to Mark Millard from comment #27)

[I tend to experiment with using system clang for
targeting powerpc64 and powerpc. Thus my context is
odd for what compiler I tend to have around.]

Looks like I also needed to use WITHOUT_CLANG_IS_CC
(or the matching one for gcc for the normal sort of
build context) to avoid overlaps with the
freebsd-gcc-6.3.0.txz content.

I'll note that for WITH_CLANG_IS_CC there is a /usr/bin/CC
script that is installed:

# more /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils/usr/bin/CC
#!/bin/sh
# $FreeBSD: head/usr.bin/clang/clang/CC.sh 292950 2015-12-30 16:14:30Z dim $
# This file is in the public domain.
exec /usr/bin/c++ "$@"

The /wrkdirs/usr/ports/base/gcc/work/pkg/freebsd-gcc-6.3.0.txz
produced in my context for base/gcc does not seem to have such
to put in place:

# tar -tf /wrkdirs/usr/ports/base/gcc/work/pkg/freebsd-gcc-6.3.0.txz | more
+COMPACT_MANIFEST
+MANIFEST
. . .
/usr/bin/c++
/usr/bin/cc
/usr/bin/cpp
/usr/bin/g++
/usr/bin/gcc
/usr/bin/gcov
. . .

I do not know if anything needs /usr/bin/CC to be around or not.



Side note:

Panics in fork activity on amd64 have sidelined my progress on the
powerpc64 targeted base/* testing. I'm not likely to get through it
this weekend. Instead the bias is to help identify what head version
is the first to get the panics on amd64 (and possibly others).