DragonFlyBSD

: Using recent HEAD (April 12th 2009) buildkernel fails building 2.2-RELEASE.

The problem is due to running old env(1), which is part of the bootstrap tools
of the 2.2 release, in a host system with new libc/setenv(3). Here is the deal:

When you supply a "value=name" string to the old env(1), it doesn't actually
break it into 2 pieces (ie null terminate on =). It just creates 2 pointers, one
pointing to the start of "value" and one to the start of "name". These pointers
are subsequently passed to setenv(3). When new setenv(3) encounters the "=" as
part of the "name" it fails with EINVAL, which is exactly what it should do,
being in compliance with the POSIX standard.

So, how did it work with old (prior to recent libc changes) setenv(3) ?
Well, it seems that old setenv(3) just skipped all "=" in the "name". That said,
it was actually possible to call env with foo=bar=lala=123 and a variable named
"foo=bar=lala" would be created and assigned a value of "123".

My suggestion is to backport env.c changes¹ to the 2.2 branch. Hopefully this
would not break anything. I expect the previous insanity to be replaced by
something like this: calling env with foo=bar=lala=123 will cause the creation
of a "foo" variable, assigned with "123" value (= characters are ignored both in
value and in name). I am building a 2.2 release as I write this, to make sure
that building 2.2 under -current, doesn't break building 2.2 in a
pre-libc-changes machine.

If anyone is willing to test [1] with 2.0 or 2.2 release that would help. Also,
thomas, can you confirm that this patch unbreaks the 2.2 build under current ?

Cheers,
Stathis

[1] http://leaf.dragonflybsd.org/~beket/env.diff

:Well, it seems that old setenv(3) just skipped all "=" in the "name". That said,
:it was actually possible to call env with foo=bar=lala=123 and a variable named
:"foo=bar=lala" would be created and assigned a value of "123".

Just checked on leaf (running 2.1.1) and it seems that it's slightly more
complicated:

-bash-3.2$ env foo=bar=lala=123 printenv foo=bar=lala
123
-bash-3.2$ env foo=bar=lala=123 printenv foo=bar
lala=123
-bash-3.2$ env foo=bar=lala=123 printenv foo
bar=lala=123
-bash-3.2$

(three variables created, not just one)

Bottom line is that old env/old setenv was playing together nicely (although
allowed insane results to be produced under certain circumstances), whereas old
env/new setenv don't any more. What remains to be seen is whether new env/old
setenv is an accepted combination.

Anyway, I'll keep you up to date with any results from my tests.

Cheers, Stathis

On HEAD building 2.2-RELEASE with your patch applied doesn't fail.

So I guess that it works as expected (new env(1) implementation,
i.e. what is in HEAD, and also what patch results in,
does work as expected, both with old end new setenv(3));
i.e. no other place in build(7) use difference in old and new setenv(3).

I do feel it a little backwards to change old source to get it build on HEAD;
it will also only solve problem in revisions where change is made,
e.g. 2.2-RELEASE and 2.0-RELEASE, as you suggest;
but if this is best solution, lets go ahead.

I'm not sure which guarantees we have on building old DragonFly releases
on newer system, but it sure is a nice feature. Is it documented some place?

Re. multiple '=' in env(1) assignment: SUSv3 setenv(3) says that variable name
isn't allowed to contain '='. So your test below mixing new env(3) with old
setenv(3) shows that correct assignment is made (to foo).
Apart from that it seems like printenv(1) bug that variable name with '='
doesn't result in error (please try 'env foo=bar=lala=123 printenv').

-thomas

Re. difference in old and new setenv(3): man page for old setenv(3):
http://gitweb.dragonflybsd.org/dragonfly.git/blob/0b84df5c43751fc53e8aa138fe3bc
51576583de7:/lib/libc/stdlib/getenv.3
..
For compatibility with differing environment conventions,
the given arguments
.Ar name
and
.Ar value
may be appended and prepended,
respectively,
with an equal sign
.Dq Li \&= .
..

On HEAD building 2.0-RELEASE with your patch applied doesn't fail.

I will commit patch in case to 2.2-RELEASE & 2.0-RELEASE in one week
if no one objects.

-thomas

Salute.

Let me summarize where we stand. Back porting the env(1) changes to the 2_2 branch:

1) unbreaks the build solely of 2.2 under -current.
2) it doesn't affect (i.e., break) the build of 2.2 under a 2.2 host system
3) it doesn't affect (i.e., break) the build of 2.2 under a 2.0 host system

(Mind that I didn't back port the patch to 2_0, so I can't comment on it)

: I'm not sure which guarantees we have on building old DragonFly releases
: on newer system, but it sure is a nice feature. Is it documented some place?

I don't know either, but I'm really new here. Anyone ?

I would expect to be able to build the exact previous release from where I am,
e.g. if the host is 2.2 be able to build 2.0. Not sure if it's desired to go
further in the past and build say 2.0 under -current.

: Re. multiple '=' in env(1) assignment: SUSv3 setenv(3) says that variable name
: isn't allowed to contain '='. So your test below mixing new env(3) with old
: setenv(3) shows that correct assignment is made (to foo).

Yes you are right. I got ashtray by printenv(1).

Regarding the possibility to ap/prepend '=' to name/value when calling
setenv(3), this stays unaffected given that patch in discussion touches only env(1).

: I do feel it a little backwards to change old source to get it build on HEAD;
: it will also only solve problem in revisions where change is made,

I'm not excited either, but given the circumstances, this was the best I could
come up with.

Cheers,
Stathis

Fixed by commit 31e17398948035bd0ce33d814c7a1e587995243a;
thank you.

-thomas