Building/updating port sysutils/u-boot-pine64 fails with the error shown below. This might be du to /usr/ports/CHANGES: 20240229: AUTHOR: tijl@FreeBSD.org [...] ===> Configuring for u-boot-pine64-2024.07 (cd /usr/ports/sysutils/u-boot-pine64/work/u-boot-2024.07; /usr/bin/env MAKE=gmake PYTHON="/usr/local/bin/python3.11" PKG_CONFIG=pkgconf XDG_DATA_HOME=/usr/ports/sysutils/u-boot-pine64/work XDG_CONFIG_HOME=/usr/ports/sysutils/u-boot-pine64/work XDG_CACHE_HOME=/usr/ports/sysutils/u-boot-pine64/work/.cache HOME=/usr/ports/sysutils/u-boot-pine64/work TMPDIR="/tmp" PATH=/usr/ports/sysutils/u-boot-pine64/work/.bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin PKG_CONFIG_LIBDIR=/usr/ports/sysutils/u-boot-pine64/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig SHELL=/bin/sh CONFIG_SHELL=/bin/sh CROSS_COMPILE=aarch64-none-elf- PYTHON=/usr/local/bin/python3.11 SCP=/dev/null BL31=/usr/local/share/atf-sun50i_a64/bl31.bin OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include OPENSSLLIB=/usr/lib XDG_DATA_HOME=/usr/ports/sysutils/u-boot-pine64/work XDG_CONFIG_HOME=/usr/ports/sysutils/u-boot-pine64/work XDG_CACHE_HOME=/usr/ports/sysutils/u-boot-pine64/work/.cache HOME=/usr/ports/sysutils/u-boot-pine64/work TMPDIR="/tmp" PATH=/usr/ports/sysutils/u-boot-pine64/work/.bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin PKG_CONFIG_LIBDIR=/usr/ports/sysutils/u-boot-pine64/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local CC="cc" CFLAGS="-O2 -pipe -fno-strict-aliasing " CPP="cpp" CPPFLAGS="" LDFLAGS=" " LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -fno-strict-aliasing " BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" gmake ARCH=arm V=1 HOSTCFLAGS="-O2 -pipe -fno-strict-aliasing -I/usr/include" HOSTLDFLAGS=" -L/usr/lib" DESTDIR=/usr/ports/sysutils/u-boot-pine64/work/stage pine64_plus_defconfig) : invalid option -- D Usage: gmake [options] [target] ... Options: -b, -m Ignored for compatibility. -B, --always-make Unconditionally make all targets. -C DIRECTORY, --directory=DIRECTORY Change to DIRECTORY before doing anything. -d Print lots of debugging information. --debug[=FLAGS] Print various types of debugging information. -e, --environment-overrides Environment variables override makefiles. -E STRING, --eval=STRING Evaluate STRING as a makefile statement. -f FILE, --file=FILE, --makefile=FILE Read FILE as a makefile. -h, --help Print this message and exit. -i, --ignore-errors Ignore errors from recipes. -I DIRECTORY, --include-dir=DIRECTORY Search DIRECTORY for included makefiles. -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg. --jobserver-style=STYLE Select the style of jobserver to use. -k, --keep-going Keep going when some targets can't be made. -l [N], --load-average[=N], --max-load[=N] Don't start multiple jobs unless load is below N. -L, --check-symlink-times Use the latest mtime between symlinks and target. -n, --just-print, --dry-run, --recon Don't actually run any recipe; just print them.
(In reply to O. Hartmann from comment #0) You have reported 6 "invalid option -- D" reports (counting this one) over time, all still listed as "New": sysutils/u-boot-pine64 sysutils/edk2 misc/shared-mime-info x11-wm/libwraster net/openldap26-server devel/gcc-arm-embedded (More detail is listed later.) It seems unlikely that the individual ports are each independently wrong. Also, I did not see such failures in the logs from the official package builder activities. (I've not looked at all the history, however.) It might be that this is a portmaster problem. Does the same problem occur for use of make to build the ports directly? If they fail with just make, then most likely there is an interaction with prior installed packages/ports that are no installed in the poudriere builder's jail during the poudriere builder's activity for the specific port being built. Some problem-isolation activity investigating such distinctions likely would be appropriate. For reference: ID▼ Product Component Assignee Status▲ Resolution Summary Changed▼ 281730 Ports & Packages Individual Port(s) uboot@FreeBSD.org New --- sysutils/u-boot-pine64: portmaster failure: : invalid option -- D 16:30:59 [+] 280076 Ports & Packages Individual Port(s) uboot@FreeBSD.org New --- sysutils/edk2: portmaster: : invalid option -- D 2024-07-01 [+] 278684 Ports & Packages Individual Port(s) desktop@FreeBSD.org New --- misc/shared-mime-info: portmaster failure: invalid option -- D 2024-06-27 [+] 277961 Ports & Packages Individual Port(s) hrs@FreeBSD.org New --- x11-wm/libwraster: fail to build with portmaster: gmake error: : invalid option -- D 2024-06-19 [+] 277954 Ports & Packages Individual Port(s) delphij@FreeBSD.org New --- net/openldap26-server: using portmaster: build failure: : invalid option -- D 2024-04-07 [+] 278198 Ports & Packages Individual Port(s) lev@FreeBSD.org New --- devel/gcc-arm-embedded: portmaster failure: : invalid option -- D 2024-04-06 [+]
No problem here building directly or with poudriere.
(In reply to Emmanuel Vadot from comment #2) I'll note that if the problem can be replicated with using just make (no portmaster), then in the port's make activity the issue might be tied to: 20240229: AUTHOR: tijl@FreeBSD.org A new command SETENVI that clears the environment and a new variable WRK_ENV that contains a basic environment to use with SETENVI have been added. Ports that run (parts of) the upstream build system directly using commands like "${SETENV} ${MAKE_ENV} ${MAKE_CMD} ..." should change that to "${SETENVI} ${WRK_ENV} ${MAKE_ENV} ${MAKE_CMD} ...". This way the build system runs with a clean environment without interference from the user environment or ports framework environment. Ports can add extra environment variables to WRK_ENV similar to CONFIGURE_ENV, MAKE_ENV, TEST_ENV, and so on, but WRK_ENV is used in all targets while the latter are target-specific.
@Mark Millard: As stated in one or the other PR: building via make and/or poudriere is working. @Vadot: see above.
(In reply to Mark Millard from comment #3) I'll file a PR refering this issue to ports-mgmt/portmaster
Filed PR 281732 : ports-mgmt/portmaster
(In reply to O. Hartmann from comment #0) Looking at an official build's log, what comes just after: . . . DESTDIR=/usr/ports/sysutils/u-boot-pine64/work/stage pine64_plus_defconfig) Looks like: gmake[1]: Entering directory '/wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2024.04' gmake -f ./scripts/Makefile.build obj=scripts/basic cc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -O2 -pipe -fno-strict-aliasing -I/usr/include -std=gnu11 -L/usr/lib -o scripts/basic/fixdep scripts/basic/fixdep.c rm -f .tmp_quiet_recordmcount gmake -f ./scripts/Makefile.build obj=scripts/kconfig pine64_plus_defconfig cc -Wp,-MD,scripts/kconfig/.conf.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -O2 -pipe -fno-strict-aliasing -I/usr/include -std=gnu11 -c -o scripts/kconfig/conf.o scripts/kconfig/conf.c bison -oscripts/kconfig/zconf.tab.c -t -l scripts/kconfig/zconf.y flex -oscripts/kconfig/zconf.lex.c -L scripts/kconfig/zconf.l cc -Wp,-MD,scripts/kconfig/.zconf.tab.o.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -O2 -pipe -fno-strict-aliasing -I/usr/include -std=gnu11 -Iscripts/kconfig -c -o scripts/kconfig/zconf.tab.o scripts/kconfig/zconf.tab.c cc -L/usr/lib -o scripts/kconfig/conf scripts/kconfig/conf.o scripts/kconfig/zconf.tab.o aarch64-none-elf-gcc -E -nostdinc -I . -undef -x assembler-with-cpp ./arch/../configs/pine64_plus_defconfig -o generated_defconfig scripts/kconfig/conf --defconfig=generated_defconfig Kconfig # # configuration written to .config # gmake[1]: Leaving directory '/wrkdirs/usr/ports/sysutils/u-boot-pine64/work/u-boot-2024.04' So it looks like the failure is associated with the line that starts with: gmake -f ./scripts/Makefile.build obj=scripts/basic Somehow what portmaster does injects a -D into something that gmake gets options to parse from. (Manually doing the same injection with a direct use of make would lead to the same, not that I know what the injection is.)