From Newsgroup: muc.lists.freebsd.ports

--Sig_/WCiJGtLIyhfSK9KRYGST_06
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

running FreeBSD CURRENT and FreeBSD 15-STABLE on several machines, I face s= ome issues with the
traditional way of compiling ports and the more resource-eating way with po= udriere.

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/li= bwraster which is
still open). Those ports fail in an "unclean natural" environment while com= piling in the
artificial sterile poudriere environment. In almost all cases the problem i=
s 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 a= nd/or devel/xtensa-esp-elf).

The non-official port compiles flawless within recent FreeBSD CURRENT and 1= 5-STABLE with
poudriere-devel.=20

It fails on all boxes running CURRENT and 15-STABLE using "make all": It f= ails in those
portions of the make process while "do build" uses ${SETENV} instead of ${S= ETENVI}
[${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 th=
at 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 cha= nge 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 abou=
t the PORTS
framework, the role of the environment and so on.
I almost changed EVERY posiible permutation of the line (see Makefile of xt= ensa-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 bet= ween 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 occure= nce of "${SETENV}"
with "${SETENVI} ${WRK_ENV}" as suggested in the above mentioned reference =
in CHANGES.

Thanks in advance

Oliver



--=20

A FreeBSD user

--Sig_/WCiJGtLIyhfSK9KRYGST_06
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaNPaGgAKCRCxzvs8Oqok r83VAQDk7/qHd0fW0z5yFoEAUoa1vouE6S0XkRTfDzSFzy27KgEAg6oYp7AFYsQh bBMeaPoxOFtTNwrLTI+kJDbIZajnGgk=
=fLC+
-----END PGP SIGNATURE-----

--Sig_/WCiJGtLIyhfSK9KRYGST_06--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 24 Sep 2025, at 13:46, A FreeBSD User <freebsd@walstatt-de.de> wrote:

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

It seems very likely that on your system(s), "make" actually invokes GNU make, not BSD make. What is the output of "which make" on your system?
-Dimitry
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--Sig_/2ugjTBU.nQSzq.xN71Y4bKG
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Am Tage des Herren Wed, 24 Sep 2025 13:50:09 +0200
Dimitry Andric <dim@FreeBSD.org> schrieb:

On 24 Sep 2025, at 13:46, A FreeBSD User <freebsd@walstatt-de.de> wrote:

running FreeBSD CURRENT and FreeBSD 15-STABLE on several machines, I fa=

ce some issues with

the traditional way of compiling ports and the more resource-eating way=

with poudriere.

=20
Some ports when compiled via "cd /usr/ports/PORT; make all" do fail wit=

h an obscur error

reporting
=20
: invalid option -- D =20

=20
It seems very likely that on your system(s), "make" actually invokes GNU =

make, not BSD make.

What is the output of "which make" on your system?
=20
-Dimitry
=20
=20

ohartmann@thor [xtensa-esp-elf]: which make
/usr/bin/make

and root:
root@thor:/usr/ports/devel/xtensa-esp-elf # which make
/usr/bin/make

root@thor:/usr/ports/devel/xtensa-esp-elf # make -V MAKE
make

root@thor:/usr/ports/devel/xtensa-esp-elf # make -V GMAKE
/usr/local/bin/gmake



--=20

A FreeBSD user

--Sig_/2ugjTBU.nQSzq.xN71Y4bKG
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaNPlbAAKCRCxzvs8Oqok r4XnAQCe2yCwzCe6LuIUIU0DJLbcvxIyGIDyogGQEBsKPaCuxgEAnQGdjAyCNQuC G/HZJvCdGFEpixLq2Wo3nlAl4agBiw4=
=GVY9
-----END PGP SIGNATURE-----

--Sig_/2ugjTBU.nQSzq.xN71Y4bKG--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--Sig_/neY0+T5ufq5RFZsNN/Z0BtW
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am Tage des Herren Wed, 24 Sep 2025 19:17:23 +0200
T=C4=B3l Coosemans <tijl@FreeBSD.org> schrieb:

On Wed, 24 Sep 2025 13:46:07 +0200 A FreeBSD User wrote:

Hello,
=20
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.
=20
Some ports when compiled via "cd /usr/ports/PORT; make all" do fail
with an obscur error reporting
=20
: invalid option -- D
=20
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:.
=20
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).
=20
The non-official port compiles flawless within recent FreeBSD CURRENT
and 15-STABLE with poudriere-devel.=20
=20
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:
=20
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):
=20
[...]
=20
do-build:
ORIG:
cd ${BUILD_WRKSRC} && ${SETENV} ${MAKE_ENV} ${BUILD_ENV} ./ct-ng bu=

ild

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

=20
=20
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. =

=20

=20
Is your ports tree up to date because this appears to have been fixed in https://cgit.freebsd.org/ports/commit/?id=3Db8bbb207f55db
=20

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 po=
rt 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 fin=
e as long as it is compiled in poudriere (also up to date with up to date t= rees 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 run= ning either portmaster or make all does fail as I described above. I refere=
d 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 rel= uctant port from github. When patching the portions of the Makefile respons= ible for building, I'm able to get rid of the
" : invalid option -- D" issue - of which the cukprit mutually has been ide= ntified but then I
run in seroius trouble at the Makefile's section "do-build": the process t= hen complains about
missing source file archive (picolibc-esp) - which is definitely present an=
d which is not
complained about by the poudriere build process.
At this point I'm pretty confident that poudriere and the traditional way a=
re different, q.e.d.

I'd like to understand to fix the problem, otherwise I'm drifting around li=
ke 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 th=
e make/portmaster
does not.=20

Kind regards and thanks,
Oliver

--=20

A FreeBSD user

--Sig_/neY0+T5ufq5RFZsNN/Z0BtW
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaNWFwAAKCRCxzvs8Oqok r6vAAP9bku4fO0EKcZ6rWahq0YPv++z8G65373ssNFcAqAdLHAEAiR9SR+lNTUyW roTkNIHbDZQTBeGM9W3VsdV5kyXH/gs=
=+T0K
-----END PGP SIGNATURE-----

--Sig_/neY0+T5ufq5RFZsNN/Z0BtW--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

A FreeBSD User <freebsd_at_walstatt-de.de> wrote on
Date: Thu, 25 Sep 2025 18:10:45 UTC :

Am Tage des Herren Wed, 24 Sep 2025 19:17:23 +0200
T-|l Coosemans <tijl@FreeBSD.org> schrieb:

On Wed, 24 Sep 2025 13:46:07 +0200 A FreeBSD User wrote:

Hello,

. . .

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):

. . .

. . .

. . . As mentioned, poudriere does the job in its obscure ways. . . .

[I'm not trying to reference any build-time-frame
issues here. I'm also limiting this to one aspect
or test for helping isolate the issue, by having
a context that does not, of itself, involve
poudriere(-evel) doing the build of the problem
port yet that I expect would work.]
Replicating what poudriere does for building a specific
port-package is conceptually rather simple, presuming
prior builds of the the port-packages for each
build-dependency, and for covering each
library-dependency, and for each run-dependency:
) Start from a clean installation of a chroot/jail world (no packages)
) Install pkg
) Install the port-packages for the dependencies referenced
) (if correctly done: here only the 1 specific port/package needs to be built) ) build the problematical port via make
) create the package from the installed port
I expect that if you did this for the failing port
you would find that the "build the problematical port
via make" would work just fine.
I'll note that just using "make" as the overall way
to build installs more into the system than is indicated
to install above --and leaves it there for later stages
of the activity as it goes along. What I expect is that
the interference with the build is from some of those
extra installations. But I've never managed to identify
what injects the "-D" when looking at past submittals
of examples of the "-D" injection problem:
sysutils/edk2 [Bug 280076]
sysutils/u-boot-pine64 [Bug 281730]
Various ports do not meet the criteria of being
invariant for their build behavior when varying
what other ports are already installed at the
time make tries to build the port in question.
Implementing such invariance for such changes in
context can be difficult. Contributions to an
example lack of invariance can be difficult to
track down.
In part the above is from considering how I might manage
to better isolate a smaller example that shows the
injection of the "-D" by mixing in some, but not all
of the "extra" installs that stick around when make
is used as the overall way to build.
I do not claim that I'll make progress any time soon.
But it seems to be a potential way forward.
===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

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
T-|l Coosemans <tijl@FreeBSD.org> 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,...
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--Sig_/5dFvDqGfYLpwv2UKGC/njx8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am Tage des Herren Fri, 26 Sep 2025 17:56:08 +0200
T=C4=B3l Coosemans <tijl@FreeBSD.org> 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
T=C4=B3l Coosemans <tijl@FreeBSD.org> schrieb: =20

On Wed, 24 Sep 2025 13:46:07 +0200 A FreeBSD User wrote: =20

Hello,
=20
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.
=20
Some ports when compiled via "cd /usr/ports/PORT; make all" do fail
with an obscur error reporting
=20
: invalid option -- D
=20
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:.
=20
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).
=20
The non-official port compiles flawless within recent FreeBSD CURRENT
and 15-STABLE with poudriere-devel.=20
=20
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:
=20
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):
=20
[...]
=20
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
=20
=20
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. =20

=20
Is your ports tree up to date because this appears to have been fixed
in https://cgit.freebsd.org/ports/commit/?id=3Db8bbb207f55db =20

=20
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).
=20
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.
=20
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.
=20
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.=20
=20
Kind regards and thanks,
Oliver =20

=20
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, so= metimes adding
${WRK_ENV} additionaly.

In most cases the issue occurs in "build" or "do-build" (of the make framew= ork).

In the reported case this is complete gone wild, even "make all" starts get= ting rogue,

I focussed too much on the "do-build" or "build" part of the Makefile, mayb=
e also the
"do-configure" and "configure" parts are highly sensitive to this SETENV/SE= TENVI issue. There
fore, one has too understand the software the FreeBSD's port system is targ= etting 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=20
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 tod= ay). adapting and
building with poudriere - no problem. Having a "polluted" ports tree with t= his specific port,
even "portmaster" AND "make all" fail=20

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

--=20

A FreeBSD user

--Sig_/5dFvDqGfYLpwv2UKGC/njx8
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaNepPAAKCRCxzvs8Oqok r7A3AQCJenQh9QewKT5dELrkCRzjVpmWC8zJnjv3Yd8W3IMDqgEAjI4di3pNMpMb 3bd9qPj+GKihJt7MvujtT3pg0QG01gQ=
=c/sC
-----END PGP SIGNATURE-----

--Sig_/5dFvDqGfYLpwv2UKGC/njx8--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

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
T-|l Coosemans <tijl@FreeBSD.org> 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
T-|l Coosemans <tijl@FreeBSD.org> 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
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sat, 27 Sep 2025 11:06:41 +0200 A FreeBSD User wrote:

Am Tage des Herren Fri, 26 Sep 2025 17:56:08 +0200
T-|l Coosemans <tijl@FreeBSD.org> 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
T-|l Coosemans <tijl@FreeBSD.org> 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

Add the following line to do-build and comment out the other lines:
${SETENV} ${BUILD_ENV} env | grep MAKE
Then run 'make build' and see if it prints anything.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2