base/binutils for my attempted powerpc64 cross build target [from amd64 head -r308247M] failed for lack of a "gcc": > Script started on Tue Nov 8 18:53:40 2016 > Command: make CROSS_TOOLCHAIN=powerpc64-gcc CROSS_SYSROOT=/usr/obj/DESTDIRs/xtoolchain-powerpc64-installworld package . . . > Making info in doc > gmake[5]: Entering directory '/usr/obj/portswork/usr/ports/base/binutils/work/binutils-2.25.1/bfd/doc' > gcc -o chw$$ \ > -I.. -I./.. -I./../../include -I./../../intl -I../../intl ./chew.c; \ > /bin/sh ./../../move-if-change \ > chw$$ chew; \ > touch chew.stamp > /bin/sh: gcc: not found > mv: rename chw79264 to chew: No such file or directory > ./chew -f ./doc.str < ./../aoutx.h >aoutx.tmp > ./chew -f ./doc.str < ./../archive.c >archive.tmp > ./chew -f ./doc.str < ./../archures.c >archures.tmp > /bin/sh: ./chew: not found > gmake[5]: *** [Makefile:798: aoutx.stamp] Error 127 > gmake[5]: *** Waiting for unfinished jobs.... > /bin/sh: ./chew: not found > gmake[5]: *** [Makefile:805: archive.stamp] Error 127 > /bin/sh: ./chew: not found > gmake[5]: *** [Makefile:812: archures.stamp] Error 127 > gmake[5]: Leaving directory '/usr/obj/portswork/usr/ports/base/binutils/work/binutils-2.25.1/bfd/doc' > Making info in po To get as far as the above I first had to rebuild the build prerequisites for binutils (devel/binutils): I had used pkg autoremove at some point and the lack of (for example) devel/bison stopped my first attempt at building base/binutils : base/binutils did not cause a build of its build prerequisites. Context details: > # uname -apKU > FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r308247M: Thu Nov 3 04:05:55 PDT 2016 markmi at FreeBSDx64:/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC-NODBG amd64 amd64 1200014 1200014 > # svnlite info | grep "Re[lv]" > Relative URL: ^/head/base/binutils > Revision: 424540 > Last Changed Rev: 421584
I probably should have noted that based on reports of the modern devel/binutils (2.27) being incompatible with use for powerpc64 and/or powerpc I've an older master port (devel/bintuils) checked out and so base/binutils here targets powerpc64 having: FreeBSD-binutils-2.25.1_3,1 # svnlite info /usr/ports/devel/binutils | grep "Re[lpv]" Relative URL: ^/head/devel/binutils Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 416639 Last Changed Rev: 416639
The notation base/binutils seems to have confused things: This is about the port, not the base system files. So I've added ports/head before base/binutils in the Summary. I've also put back the port version. I can not fix the assignee: it should not be freebsd-powerpc@FreeBSD.org
Well now it's even more confusing actually, should it read (since it's about ports) "devel/binutils (r421584) ..." instead? > it should not be freebsd-powerpc@FreeBSD.org Perhaps it's not entirely accurate, but it's IMHO better than umbrella freebsd-ports-bugs@FreeBSD.org. If you can think of more appropriate party, I'd be happy to reassign.
(In reply to Alexey Dokuchaev from comment #3) No. There are two ports: ports/head/base/binutils ports/head/devel/binutils This is about the first of those. See https://svnweb.freebsd.org/ports/head/base/ for the lest of "base ports", including binutils.
(In reply to Mark Millard from comment #4) lest -> list: See https://svnweb.freebsd.org/ports/head/base/ for the list of "base ports", including binutils.
(In reply to Alexey Dokuchaev from comment #3) While my example context was powerpc64 I'd be surprised if that is the only cross build context to have such problems. I've no clue what contexts others may have tried to have direct evidence of what happens for other architectures.
> While my example context was powerpc64 I'd be > surprised if that is the only cross build context > to have such problems. It would be nice if you could've attempted to investigate if other contexts are affected as well as it might help draw more attention from the interested parties. As it is, this PR looks like powerpc64-specific. Throwing back to the pool, sorry for the hassle.
(In reply to Alexey Dokuchaev from comment #7) I do not expect that ports/head/base is intended to be used for TARGET_ARCH's that have well working system-clang support. (Although likely it should work even if those with well-working system-clang's are not what drives the need for ports/head/base .) Possibly a different target environment would be of more general interest. But for me it was powerpc64 (and powerpc) that was of interest because of lack of sufficient support by the system clang compilers/toolchain and I have access to such hardware. The README: https://svnweb.freebsd.org/ports/head/base/README?revision=421582&view=markup uses sparc64 an example. But I have no sparc64 systems to test build results on. I do have access to powerpc64 and powerpc examples. everything else that I have access to has working system-clang support and would not need ports/head/base to be used. In case is helps avoid future confusions: this was a amd64 -> powerpc64 cross build attempt. The actual execution environment was amd64 and powerpc64 was the target for the type of files to be produced but no actual powerpc64 processor was involved since things did not get far enough to have something to test on a powerpc64 system. In terms of my original wording: "base/binutils for my attempted powerpc64 cross build target [from amd64 . . ." Execution on amd64 is another reason for freebsd-powerpc@FreeBSD.org being a questionable assignment.
Fair enough. Let's hope that it all would finally get cleared up and fixed. Please feel free to further edit the PR yourself (or ask for assistance) to bring more details to the issue. Thanks!
(In reply to Mark Millard from comment #1) Correction to an claim I made in comment #1 back on 2016-Nov-10: While comment #1 is correct about what I did as far as the devel/binutils prerequisite goes it turns out that devel/binutils 2.27 works and so I did not have to revert to an older vintage. For the purposes of this submittal it should not matter which of the two vintages of devel/binutils is/was used. And, yes, ports/head/base/* use requires (uses): ports/head/devel/binutils so both binutils ports are involved overall.
May be setting the Hardware to Any instead of to the target of the cross build would help avoid confusions for this bugzilla report against ports/head/base/binutils . So I'm changing that. I'm guessing that listing amd64 (the execution environment for my example cross build) would also be confusing. That is why I picked Any. I'll also note that via various workarounds in order to find other problems at later stages I also submitted 214401 through 214405 against: ports/head/base/* materials and what they produce. These too might be confusing for base/binutils and base/gcc references that are actually for: ports/head/base/binutils ports/head/base/gcc
I think this is resolved by the changes in bug 224217. Please confirm.
(In reply to Steve Wills from comment #12) I did not have the specific gcc problem when I tried to build based on the newer material. So the specifics have been taken care of. Points of note . . . I did have to first have installed (not via base/binutils): devel/bison and devel/gmake and a lang/perl5.* (I had 5.24 installed.) The README did not indicate such a requirement. (base/binutils did not build them sufficiently on its own.) There are what may be odd relationships for some file names produced for to-be-installed files for: base/binutils vs. devel/powerpc64-binutils vs. base/gcc vs. devel/powerpc64-gcc 3 of the 4 use powerpc64-unknown-freebsd12.0- prefixes but devel/powerpc64-binutils uses powerpc64-freebsd- prefixes. (Or did last I built it on a powerpc64.) There are the /usr/bin/ vs. /usr/local/bin/ sorts of path differences as well so the matching names for devel/powerpc64-gcc and base/gcc make for ties to path order.
The specific "gcc" problem for base/binutils has been fixed in the modern update.
(In reply to Mark Millard from comment #13) "PATH order": not "path order".
(In reply to Mark Millard from comment #13) Turns out that a more modern devel/powerpc64-binutils does use powerpc64-unknown-freebsd12.0- prefixes, just like base/binutils does. 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. ( /usr/bin/ vs. /usr/local/bin/ and the like.)