Date: Tue, 23 Nov 1999 15:57:55 +0100 From: Marcel Moolenaar <marcel@scc.nl> To: Peter Wemm <peter@netplex.com.au> Cc: freebsd-arch@freebsd.org Subject: Re: Cross-building (was: cross compilation goals) Message-ID: <383AAB73.966D3D60@scc.nl> References: <19991123134900.D962E1CC8@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote: > > Marcel Moolenaar wrote: > > > 1. Remove support for /etc/objformat > > ------------------------------------ > The purpose of /etc/objformat is to allow overriding <machine/param.h> which > defines the system default format. Since it isn't practical to recompile the > system to change the default for some development task for a few days, we have > an override of the default. This can be accomplished by using the environment variable as well (see below). Is it possible to make an aout world (I don't mean legacy stuff) or a world with an objformat other than ELF? In other words do we actively support multiple object formats? > $OBJFORMAT is treated slightly differently and had a slightly different > role. It's purpose was to allow conditional overrides. Certain places in > the source tree had "OBJFORMAT?= foo" which meant that the default for a > given part of the tree would be changed unless the builder had explicitly > set it. This used to be more "magic" than it is today, but I still feel > it's useful to have the two seperate. Yes. Having an environment variable to control the output of the compilation toolset is a good thing. It can be applied system wide, but also in a smaller context. It can be undone by removing it and it can be overridden again. there's nothing about /etc/objformat that can't be handled with the environment variable. So, why /etc/objformat when it can only do harm in certain cases? > Finally, as you say, we don't ship with the file present by default, so it > doesn't interfere with cross builds. I don't see why it has to be killed.. The point is that the cross-compiler is adapting to a system it shouldn't be adapting to. /etc/objformat can be read by any tool that runs on the system, including the tools to which the override does not apply. Since it's a file, you cannot undo the override by removing the override, but you'll have to override the override, which makes it impossible to simply use the system default because you'll have to *know* the system default to be able to override the override. Needlessly complicated. /etc/objformat has served its purposes in the aout to elf switchover, but has lost it's function, I think. The new function you described it to be having is artificial IMO. This, I think, is also expressed in the fact that we don't have it. On systems that do have it (as described in my example) it can only mess things up. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?383AAB73.966D3D60>