Re: Nonrecursive build within gcc directory

[Geoff Keating <geoffk at cygnus dot com>]

"Zack Weinberg" <zackw@stanford.edu> writes:

> There are a few issues.  The most important one is that we run into
> trouble with compilers that can't handle -c and -o simultaneously.
> I've added Autoconf logic to prevent them seeing both options
> together, but that means all the non-C front end modules wind up in
> the toplevel directory rather than where they're supposed to.

The generic way to fix this is to replace 'cc foo.c -c -o /dir/foo.o'
with 'cc foo.c -c && mv foo.o /dir/foo.o' which should work as in the
separate-source-and-.o directory case there would be no .o files in
the source directory, and in the combined case the .c file and .o file
will end up in the same directory as we wanted.  It would be good to
make this conditional on having a compiler that doesn't support -c -o,
as it's quite likely the source and object directories will be on
different filesystems and so the 'mv' has to do a real copy, which
would slow things down, and it's also not impossible that the source
directory will not be writable.

>  This is only a problem when making cross-compilers, or in a native
> build if you do make all instead of make bootstrap.  There's also a
> bug in the directory search logic in the gcc 2.95 (and all previous
> versions) preprocessor, which causes it not to be able to find
> headers for cp/parse.c.  (In short, #line messes up
> current-directory handling.)  Again, this is only a problem if you
> don't do a bootstrap (whether for cross-compilation, or otherwise).

This is a real problem for cross-compilation.  Could you fix it by
adding -I options?

-- 
- Geoffrey Keating <geoffk@cygnus.com>