A FreeBSD User <freebsd_at_walstatt-de.de> wrote on Date: Sat, 27 Sep 2025 09:06:41 UTC :
> 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: > > >>> . . . > > >> > > >> . . . > > > > > > 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 . . . > > > . . . > 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 . . . > > > . . . When patching the portions of the Makefile responsible for > > > building, I'm able to get rid of the " : invalid option -- D" issue Are you going to publish a patch that updates the files to as you have them so that someone else can attempt to reproduce your problem for after the above has been done? A point of that is to make sure to have the same file contents that you are using for the unofficial port if someone tries. > - > > > 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. . . . > > > > > > 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 [poudriere here is non-essential and not part of the problem, there is a manual sequencing that would have the same sort of build context. (I sent a message about this earlier.)] > 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. Again, can you provide a patch that others might use to reproduce the resultant files? > 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. Again, can you provide a patch that others might use to reproduce the resultant files? > The overlay used in poudriere doesn't have any is > > 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 > > > > > > . . . > > > === Mark Millard marklmi at yahoo.com
