Am Tage des Herren Fri, 26 Sep 2025 17:56:08 +0200 Tijl Coosemans <[email protected]> schrieb:
> On Thu, 25 Sep 2025 20:10:45 +0200 A FreeBSD User wrote: > > Am Tage des Herren Wed, 24 Sep 2025 19:17:23 +0200 > > Tijl Coosemans <[email protected]> schrieb: > >> On Wed, 24 Sep 2025 13:46:07 +0200 A FreeBSD User wrote: > >>> Hello, > >>> > >>> running FreeBSD CURRENT and FreeBSD 15-STABLE on several machines, I > >>> face some issues with the traditional way of compiling ports and the > >>> more resource-eating way with poudriere. > >>> > >>> Some ports when compiled via "cd /usr/ports/PORT; make all" do fail > >>> with an obscur error reporting > >>> > >>> : invalid option -- D > >>> > >>> followed by a bunch of gmake options (for instance see PR 277961, > >>> x11-wm/libwraster which is still open). Those ports fail in an > >>> "unclean natural" environment while compiling in the artificial > >>> sterile poudriere environment. In almost all cases the problem is due > >>> to "overlapping" environments, targeted by the introduction of > >>> SETENVI - see /usr/ports/CHANGES, tag 20240229:. > >>> > >>> I try to compile a well maintainded ESP32 toolchain > >>> (https://github.com/trombik/xtensa-esp32-elf, here: > >>> devel/riscv32-esp-elf and/or devel/xtensa-esp-elf). > >>> > >>> The non-official port compiles flawless within recent FreeBSD CURRENT > >>> and 15-STABLE with poudriere-devel. > >>> > >>> It fails on all boxes running CURRENT and 15-STABLE using "make > >>> all": It fails in those portions of the make process while "do > >>> build" uses ${SETENV} instead of ${SETENVI} [${WRK_ENV}]. After > >>> fixing that I'm stuck in the last step of do-build: > >>> > >>> I do not want to go into too much details here since I want to point > >>> out that the real world "make all" differs in a significant way from > >>> the artificial sterile way of doing poudriere (which is to much > >>> efford on development/experimental platforms where we change options > >>> very often). > >>> I'd like to understand the underlying behaviour to fix the > >>> misbehaviour in "make all" - this seems to be very hard and I fear > >>> that I miss something, some knowledge about the PORTS framework, the > >>> role of the environment and so on. I almost changed EVERY posiible > >>> permutation of the line (see Makefile of xtensa-esp-elf): > >>> > >>> [...] > >>> > >>> do-build: > >>> ORIG: > >>> cd ${BUILD_WRKSRC} && ${SETENV} ${MAKE_ENV} ${BUILD_ENV} ./ct-ng > >>> build VARIANT1: > >>> cd ${BUILD_WRKSRC} && ${SETENVI} ${MAKE_ENV} ${BUILD_ENV} > >>> ./ct-ng build VARIANT2: > >>> cd ${BUILD_WRKSRC} && ${SETENVI} ${WRK_ENV} ${MAKE_ENV} > >>> ${BUILD_ENV} ./ct-ng build > >>> > >>> > >>> The great magic here seems to be one needs to understand the > >>> difference between poudriere's enviroenment and the environment of my > >>> account on several boxes. My (blunt and stupid) approach is to > >>> replace on a bail out the first occurence of "${SETENV}" with > >>> "${SETENVI} ${WRK_ENV}" as suggested in the above mentioned > >>> reference in CHANGES. > >> > >> Is your ports tree up to date because this appears to have been fixed > >> in https://cgit.freebsd.org/ports/commit/?id=b8bbb207f55db > > > > Sorry for late responding. > > I made it a habit to keep almost everything on a daily basis up to > > date and before compiling a port or something related to the OS I do a > > pull (git). > > > > The port deve/xtensa-esp-elf is the official port in the ports tree. > > The port does not cover ESP32 RISCV32 based and doesn't cover latest > > ESP-IDF 5.5. > > > > I try to compile https://github.com/trombik/xtensa-esp32-elf which does > > compile fine as long as it is compiled in poudriere (also up to date > > with up to date trees and an overlay covering the additional port). As > > mentioned, poudriere does the job in its obscure ways. Replacing the > > port devel/xtensa-esp-elf with the port by this Japanese developer > > mentioned above in the tree an running either portmaster or make all > > does fail as I described above. I refered to some ports and PRs with > > similar issues - and in most cases with those ports, the introduction > > of SETENVI solves the problem. But not with the reluctant port from > > github. When patching the portions of the Makefile responsible for > > building, I'm able to get rid of the " : invalid option -- D" issue - > > of which the cukprit mutually has been identified but then I run in > > seroius trouble at the Makefile's section "do-build": the process > > then complains about missing source file archive (picolibc-esp) - > > which is definitely present and which is not complained about by the > > poudriere build process. At this point I'm pretty confident that > > poudriere and the traditional way are different, q.e.d. > > > > I'd like to understand to fix the problem, otherwise I'm drifting > > around like a dead man in the water hoping others fix the problem by > > accident. That is not an option. I'd like to understand why poudriere > > builds the unaltered port without any flaws and the make/portmaster > > does not. > > > > Kind regards and thanks, > > Oliver > > You'll have to make all the same changes to the overlay that > b8bbb207f55db made: add WRK_ENV and replace all SETENV with SETENVI. I do, I did, of course. The overlay used in poudriere doesn't have any issue. The issue arise using portmaster, then this spooky mixing up of make/gmake occurs and can be resolved by addapting ${SETENVI} at places where ${SETENVI} is residing, sometimes adding ${WRK_ENV} additionaly. In most cases the issue occurs in "build" or "do-build" (of the make framework). In the reported case this is complete gone wild, even "make all" starts getting rogue, I focussed too much on the "do-build" or "build" part of the Makefile, maybe also the "do-configure" and "configure" parts are highly sensitive to this SETENV/SETENVI issue. There fore, one has too understand the software the FreeBSD's port system is targetting for - and I do not ... And, for a reminder, I'm confused by this port (not officially in the ports tree): https://github.com/trombik/xtensa-esp32-elf and from there devel/xtensa-esp-elf devel/riscv32-esp-elf both toolchains targetting all available ESP-IDF (5.3, 54 and 5.5 as of today). adapting and building with poudriere - no problem. Having a "polluted" ports tree with this specific port, even "portmaster" AND "make all" fail > > If you want to figure out why make is different from poudriere you'll > have to find out where that -D flag is coming from. Check > /etc/make.conf, check if your /usr/ports/Mk is different from FreeBSD > git, check environment variables ("env | grep MAKE"), run "whereis make" > to see that make is /usr/bin/make, check that /usr/bin/make is actually > make and not some wrapper script or something,... > -- A FreeBSD user
pgp6f5ODBTozA.pgp
Description: OpenPGP digital signature
