Date: Wed, 18 Mar 2009 19:56:02 -0600 From: John Hein <jhein@timing.com> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: Final sanity pass: xdev Message-ID: <18881.42546.640583.971867@gromit.timing.com> In-Reply-To: <49C19F2A.10406@elischer.org> References: <18875.60334.947446.966085@gromit.timing.com> <20090315.080814.669286040.imp@bsdimp.com> <18877.57878.136116.691250@gromit.timing.com> <20090318.183646.-593221015.imp@bsdimp.com> <18881.38984.133668.539997@gromit.timing.com> <49C19F2A.10406@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote at 18:26 -0700 on Mar 18, 2009: > John Hein wrote: > > 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. In our locally grown build env, that's pretty easy to do (pass different UNAME_r at different build stages). Perhaps you could even put it into the default env for a build chroot/jail (via login.conf). As I said, it's probably not in the scope of /usr/src/Makefile*, but because we can pass in UNAME_r from a higher level having Makefile.inc1 use 'uname -r' for OSREL (as it is currently named) in cross builds seems okay to me.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18881.42546.640583.971867>