Bug 230288 - sysutil/u-boot-pine64: -r476026 vintage build failed in poudriere-devel (default gcc=8 and WITHOUT_BINUTILS= for -r336693 head context)
Summary: sysutil/u-boot-pine64: -r476026 vintage build failed in poudriere-devel (defa...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-uboot (Nobody)
Depends on:
Reported: 2018-08-02 06:43 UTC by Mark Millard
Modified: 2020-12-12 05:51 UTC (History)
4 users (show)

See Also:

. . ./logs/u-boot-pine64-2018.07_1.log (58.89 KB, text/plain)
2018-08-02 06:43 UTC, Mark Millard
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2018-08-02 06:43:28 UTC
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:

 CFLAGS:=		${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
 .if defined(INSTALL_TARGET)
 INSTALL_TARGET:=	${INSTALL_TARGET:S/^install-strip$/install/g}

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

# 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
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.
Comment 1 Mark Millard 2018-08-02 08:05:12 UTC
(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
Comment 2 Mark Millard 2018-08-02 18:49:27 UTC
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

# 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 \
+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 .
Comment 3 Emmanuel Vadot freebsd_committer 2018-08-03 03:47:47 UTC
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.
Comment 4 Mark Millard 2018-08-03 05:56:39 UTC
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.
Comment 5 Mark Millard 2018-09-18 21:05:52 UTC
(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
 .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
Comment 6 Mark Millard 2018-09-19 01:16:53 UTC
(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

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.
Comment 7 Mark Millard 2020-03-10 23:58:49 UTC
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
 .include "${MASTERDIR}/Makefile"

continues to have had no problems.

So far the change has not been adopted in
sysutils/u-boot-pine64 .
Comment 8 Daniel Engberg 2020-12-12 00:21:56 UTC
Still an issue?
Comment 9 Mark Millard 2020-12-12 05:51:00 UTC
(In reply to daniel.engberg.lists from comment #8)

I still use the addition of a:


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.