Final sanity pass: xdev

[Julian Elischer]

John Hein wrote:
> M. Warner Losh wrote at 18:36 -0600 on Mar 18, 2009:
>  > In message: <18877.57878.136116.691250 at gromit.timing.com>
>  >             John Hein <jhein at timing.com> writes:
>  > : M. Warner Losh wrote at 08:08 +0900 on Mar 15, 2009:
>  > :  > In message: <18875.60334.947446.966085 at gromit.timing.com>
>  > :  >             John Hein <jhein at timing.com> writes:
>  > :  > : An earlier patch of yours had:
>  > :  > : 
>  > :  > : .if !defined(OSREL)
>  > :  > : OSREL!= uname -r | sed -e 's/[-(].*//'
>  > :  > : .endif
>  > :  > : 
>  > :  > : But the latest (and the one committed) does not.
>  > :  > 
>  > :  > You are right... Dang.  I must have comitted the wrong thing...
>  > 
>  > There is a subtle point here that we've missed.  This gives us the
>  > version on the host, not the version of the tree we're building.  In
>  > practice, these need to be the same.  However, if we support building
>  > a 6.x cross compiler on a 7.x system, we may have to revisit.
> 
> In our build env (I'm sure you recall), it works out fine in practice
> (for most ports [*]).
> 
> Building 8.x targets on 7.x makes links like "arm-freebsd7.1-cc" but
> the cross built ports also look for that name - likely because the
> config-guess machinery uses uname also.
> 
> I'm not so sure we need to support building the other direction (7 on 8)
> since we generally don't support that direction of compatibilty, but
> if it can be done with minimal effort, that'd be good.
> 
> So, if it's just a matter of finding the appropriate cross version of
> cc or nm or whatever, this is okay.
> 
> [*] But if there is some dependency in a particular port that actually
> looks into the freebsd version and does something different based on
> version, it may be an issue.  Then on top of that, there's kernel
> version and userland version that may matter to certain ports.
> 
> Perhaps we should consider setting UNAME_r in the environment when
> building across major OS levels (possibly outside the scope of
> /usr/src/Makefile*).
> 
> At a certain point in the cross-arch / cross-major-OS-version building
> dance, we could also just say it's not supported and let people work
> it out with a native "same major" OS level build machine (possibly a
> virtual machine).

we also have this problem when running a different revision of
software in a Jail. Possibly it should be possible to set the value 
that uname responds with for a process and its' children, (even more 
so that the environment variables)
I'd like to be able to label a jail as a 7.1 jail on an 8.0 machine..

The problem in using teh single environment variable UNAME_r
or friends is that  the intermediate tools ARE running on a
different environment than the final tools so one value may not be
correct everywhere.
we sort of need one value of UNAME_r up until teh tools are built, and 
then another value for teh binary build. But even that may be not 
general enough.

> 
> 
>  > : One more thing... Now that we've switched to bsd ar, installing
>  > : gnu/usr.bin/binutils installs the gnu ar as gnu-ar.  Cross-built
>  > : ports can't find arm-freebsd8.0-ar
>  > 
>  > Doh! Thanks for the patch.  I'll run it through my QA cycle.
> 
> Okay.  Thanks for getting the 1000 monkeys to give it a test run ;)
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"