RE: crosscompiler x86->solaris2.8

["Rupert Wood" <me at rupey dot net>]

Kai Ruotto wrote:

> > The "--with-headers" configure option copies the path specified to
> > sys-include. This directory is processed by fixincludes at 
> > build time. This is all correctly documented in the manual.
>  You mean the text starting with this in the "Using and 
> Porting...." from Stallman and other GCC-developers?

I meant that the documentation for "--with-headers" is correct as
implemented.

>  - in order to not spoil the 'already suitable' newlib and glibc
> headers, installed into '$(tooldir)/include' by their own 'make
> install', when built, they will now be 'hided' from the
> 'fixincludes' by putting it to search where nothing should be...

I disagree; there's no reason that newlib and glibc shouldn't be
fixincluded. It may become necessary in the future to work around a
mistake made in an old version of one of them.

> "CROSS_INCLUDE_DIR is used only for a cross compiler. GNU CC doesn't
> install anything there."  This sounds sane, although for which
> purpose a cross-compiler would use it was left unknown... (My guess
> has been 'for system-specific', ie. for the 'local' purposes for
> which the 'LOCAL_INCLUDE_DIR' is aimed with the native-GCC).

My assumption was always the other way around: that sys-include is for
system headers whereas include is the cross-equivalent of
LOCAL_INCLUDE_DIR.

>  - someone didn't see the difference between 'system' and 
> 'standard'

Again, I don't see your point here - sys-include is
[CROSS_]SYSTEM_HEADER_DIR and CROSS_INCLUDE_DIR not SYSTEM_INCLUDE_DIR,
and STANDARD_INCLUDE_DIR is not used for cross-compiles.

> More mess will cause the fact that the produced main Makefile and
> the 'gcc/Makefile' use the option '-I$(build_tooldir)/include'

Only <3; 3+ use 

    -isystem $(build_tooldir)/include
    -isystem $(build_tooldir)/sys-include

> for searching the target headers during the build... If the headers
> are in the '$(tooldir)/sys-include', this doesn't work and is vain.

No, the path to sys-include is compiled-in as CROSS_INCLUDE_DIR.

> It is true that many targets still need their 'standard C-headers'
> being fixed for GCC, but if one uses already fixed headers with an 
> already installed cross-compiler and these will again be fixed, the
> result is a mess.

The headers aren't fixed in-situ; the fixes are placed under gcc-lib as
usual. I don't think that there's scope for accidental double-fixing of
a set of headers. I'd argue that fixincludes ought not to double-fix a
file anyway.

I see no reason to install an already-fixed set of headers into include
or sys-include when building a cross compiler; you're not gaining
anything against re-fixing the broken set and you're assuming that the
fixinclude data hasn't been updated. I don't think the time it takes to
fixinclude is significant in a GCC build.

> With the Linux-targets I have seen GCC trying to fix also the
> 'include/asm' and 'include/linux' and put them into the
> GCC_INCLUDE_DIR...

I haven't seen that, but I don't think it's unreasonable - hopefully
fixincludes found nothing to fix?

> The situation with the placement of the target headers is a mess and
> quite a lot must be done with standardizing it...

Perhaps also the include path order. Thes may be worth raising on the
primary GCC mailing list before the 3.2 major-change freeze.

> In the Solaris2-case the "Solaris2-FAQ" is a must, and one must have
> some kind of thought about where to put all the stuff which doesn't
> exist in '/usr/include' and '/usr/lib' (or were these at
> '/usr/ccs/...'?), like the X11-stuff, 'dt', 'openwin' etc.

In Solaris 2.8 at least there are symlinks from inside /usr/include to
dt and openwin. I avoid /usr/ccs/lib and /usr/ucbinclude where I can but
I don't know what the recommended practices are.

I see your point about LOCAL_INCLUDE_DIR for a single version of all
target libraries, but it's still necessary to build the binaries for all
targets and safest perhaps to associate the headers only with the
correct version of the binary rather than a common set for all binaries
that you have.

> Reporting this clash between the GCC-manual and the GCC-sources
> hasn't yet caused any actions from the GCC-developers...

JSM at least is very keen on the manual being correct, so if you get his
attention then it will probably get fixed - raising a PR against the
manual ought to work. Alternatively, submit a patch against the .texi to
gcc-patches, perhaps copying him. I don't agree completely with your
revised wording; GCC_INCLUDE_DIR still says that $(tooldir)/include is
fixincluded which I don't think is true. But it's a step in the right
direction independent of our include/sys-include disagreement :-)

Rup.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com