Created attachment 195756 [details] . . ./logs/u-boot-pine64-2018.07_1.log [Note: I was told to provide every line of the log file so I did so in the attachment.] See the attachment for the log showing the errors. Context oddities: The environment's buildworld was based on WITHOUT_BINUTILS= so ports without BUILD_DEPENDS having devel/binutils (or equivalent) but that try to use tools that would come from such will not find such tools. ( devel/powerpc64-gcc is/was an example for a WITHOUT_BINUTILS= world ) The default gcc is set to gcc8 . My /usr/ports/Mk/bsd.port.mk has: STRIP_CMD= ${TRUE} .endif DEBUG_FLAGS?= -g +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG) +CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS} +.else CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS} +.endif .if defined(INSTALL_TARGET) INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g} .endif and I put it to use. Other context information: # uname -apKU FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r336693M amd64 amd64 1200075 1200075 The "M" is mostly for powerpc family targeting via modern compilers/toolchains. (But I currently do not have access to the powerpc family hardware.) amd64 FreeBSD is running under virtualbox on a macOS machine for my current context. # 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: 476026 Last Changed Rev: 476026 I had no problem with the other sysutil/u-boot-* 's that I build, just for pine64. What built fine was: sysutils/u-boot-rpi3 | u-boot-rpi3-2018.07_1 sysutils/u-boot-rpi2 | u-boot-rpi2-2018.07_1 sysutils/u-boot-sinovoip-bpi-m3 | u-boot-sinovoip-bpi-m3-2018.07_1 # poudriere jail -l JAILNAME VERSION ARCH METHOD TIMESTAMP PATH FBSDFSSDjail 12.0-CURRENT amd64 null 2017-11-22 10:15:15 /usr/obj/DESTDIRs/clang-amd64-installworld-poud poudriere-devel is using /usr/src (the same source my system is built from). I install /usr/obj/DESTDIRs/clang-amd64-installworld-poud via the following each time I update FreeBSD versions: -j4 installworld distrib-dirs distribution DB_FROM_SRC=1 DESTDIR=/usr/obj/DESTDIRs/clang-amd64-installworld-poud I do so from the same buildworld result that I install for what I boot in virtualbox. A similar point goes for /usr/ports: poudriere-devel is using what the booted system is using.
(In reply to Mark Millard from comment #0) I forgot to say that until recently sysutils/u-boot-pine64 had been building fine in my environment. The WITHOUT_BINUTILS= started around 2018-Jul-24 and default gcc=8 started around 2018-Jul-14 ( DEFAULT_VERSIONS+=perl5=5.26 gcc=8 ). I have had problems with other ports (devel/powerpc64-gcc based) because of a WITHOUT_BINUTILS= based world. So far I've not tracked any problems down to any gcc8 use. The timing suggests WITHOUT_BINUTILS= might be contributing here but I've no specific technical evidence for such (as yet?).
The following change to sysutils/u-boot-master/Makefile was sufficient to allow sysutils/u-boot-pine64 to build in my poudriere-devel context that is based on a buildworld that uses WITHOUT_BINTUTILS. (I'm not claiming this is the best form of fix, just noting the behavior of the specific change.) # svnlite diff /usr/ports/sysutils/u-boot-master/Makefile Index: /usr/ports/sysutils/u-boot-master/Makefile =================================================================== --- /usr/ports/sysutils/u-boot-master/Makefile (revision 476026) +++ /usr/ports/sysutils/u-boot-master/Makefile (working copy) @@ -21,6 +21,7 @@ dtc>=1.4.1:sysutils/dtc \ mkimage:sysutils/u-boot-tools BUILD_DEPENDS+= ${COMPILER}:devel/${COMPILER} +BUILD_DEPENDS+= objdump:devel/binutils USES= bison gmake python:2.7,build shebangfix tar:bz2 BINARY_ALIAS= bison=${LOCALBASE}/bin/bison dtc=${LOCALBASE}/bin/dtc sed=gsed swig=swig3.0 I've not isolated where the builder environment's binutil tool(s) are put to use but this seems to solidly indicate that there is such use for sysutils/u-boot-pine64 .
Ok. I don't know what are the rule in ports for this kind of thing. The fix is clearly not good as it will bring this new dependancy for everyone but I'm not aware of a way to do otherwise.
I've changed "Hardware" to "Any" because this is unlikely to be specific to amd64 as the builder architecture for a cross build. (But my testing was limited to amd64 as the building context.) As no one else has reported using a WITHOUT_BINUTILS type context to confirm/deny duplication of the issue, I've left "importance" as "Affects Only Me" for now.
(In reply to Mark Millard from comment #4) Further experiments have shown a build race leading to a missing file that is present when looking at the expanded bulk -w save file. I'm now also using: # svnlite diff /usr/ports/sysutils/u-boot-pine64/Makefile Index: /usr/ports/sysutils/u-boot-pine64/Makefile =================================================================== --- /usr/ports/sysutils/u-boot-pine64/Makefile (revision 480053) +++ /usr/ports/sysutils/u-boot-pine64/Makefile (working copy) @@ -6,4 +6,6 @@ BOARD_CONFIG= pine64_plus_defconfig FAMILY= allwinner64 +MAKE_JOBS_UNSAFE=yes + .include "${MASTERDIR}/Makefile" in order to get reliable builds in poudriere-devel. The testing build context was on a Pine64+ 2GB configuration, e.MMC on a microsd card adapter, trim enabled (with the discard bit also enabled). (Such might change the relative timing of various operations compared to typical usage.) [My amd64 based cross build did not show the race prior to the MAKE_JOBS_UNSAFE addition.]
(In reply to Mark Millard from comment #5) I tested using MAKE_JOBS_UNSAFE=yes without having BUILD_DEPENDS+=objdump:devel/binutils and it also built in poudriere-devel just fine. So my Comment #2 is wrong and the real issue is the racy nature of the multi-process build. So far only I've only seen the symptoms for sysutils/u-boot-pine64 . Not sysutils/u-boot-rpi3 that I also build on the Pine64+ 2GB. Not sysutils/u-boot-rpi{3,2} nor sysutils/u-boot-sinovoip-bpi-m built on the amd64 context that I've been using.
My use of: # svnlite diff /usr/ports/sysutils/u-boot-pine64/Makefile Index: /usr/ports/sysutils/u-boot-pine64/Makefile =================================================================== --- /usr/ports/sysutils/u-boot-pine64/Makefile (revision 480053) +++ /usr/ports/sysutils/u-boot-pine64/Makefile (working copy) @@ -6,4 +6,6 @@ BOARD_CONFIG= pine64_plus_defconfig FAMILY= allwinner64 +MAKE_JOBS_UNSAFE=yes + .include "${MASTERDIR}/Makefile" continues to have had no problems. So far the change has not been adopted in sysutils/u-boot-pine64 .
Still an issue?
(In reply to daniel.engberg.lists from comment #8) I still use the addition of a: MAKE_JOBS_UNSAFE=yes in the Makefile to avoid the issue. I've had no problems with it present. But I've not tested not having the extra line in a long time. As it was a race condition, I'd have to use it over some time to discover if the builds sometimes fail without the extra line: not just a direct, single test. This makes it messy to declare the status.
I guess we can close this by now as there hasn't been more issues reported and the port builds fine on our build cluster. Please open a new PR if it still occurs