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.
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,...
