This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: introduce configure --with-sysroot
On Oct 25, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> But $host = $target. I built an i386 "cross" compiler, which is
> something I use daily - from a desktop x86 environment to an embedded
> one.
If it targets an embedded system, then I don't see how target = host
is really appropriate. I mean, host = target means you're creating a
native compiler, so it's perfectly reasonable for it to search
/usr/include.
I can see that it's not right for it to assume that the build system's
/usr/include has anything to do with the host and target, though, and
this is definitely something we should get at to arrange for gcc to
use one directory for build-time operations, such as fixing headers,
while still behaving as a native compiler as expected of a
host==target, in searching /usr/include or whatever default directory
the host/target system uses.
> I have a patch in my work tree which adds --enable-cross. Can you
> think of a better way, or should I submit it?
How about introducing BUILD_SYSTEM_HEADER_DIR, defined to
NATIVE_SYSTEM_HEADER_DIR if build==target and to SYSTEM_HEADER_DIR
otherwise. Then we'd use BUILD_SYSTEM_HEADER_DIR for fixinc and in
the limits.h test. In fact, there's no reason to rename the
variable. SYSTEM_HEADER_DIR is *only* used for this purpose, so we
can simply add a test for build = target when deciding whether to
override the setting.
> No local changes in the test tree at all. It seems to me that the
> directories in cppdefault.c:cpp_include_defaults should be affected by
> %R, which means passing it to cc1 somehow.
For a native compiler (even a cross-built host-x-host like the one
you're building), CROSS_SYSTEM_HEADER_DIR is not used.
CROSS_SYSTEM_HEADER_DIR is only used by the compiler on host-x-target
systems, i.e., when host != target.
I agree it may be nice to be able to tell gcc: `look, host = target,
but I want you to act as if it were a cross compiler, ok?´
--enable-cross would be a nice way to accomplish that, but you can
often do that by minimal spelling differences between host and target
(say: --host=machine-whatever-os --target=machine-cross-os) so I've
never been sufficiently bothered to implement this. I'm not sure we
really want to afford the complexity of --enable-cross; it would
require a careful review of all tests involving host and target to
determine when we want enable_cross to take precedence or not.
> I can't tell if the prefix following code in cppinit.c and prefix.c is
> supposed to be doing this, or not.
It is not.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer