Re: AIX Host -> PowerPC Linux

[Kai Ruottu <kai dot ruottu at luukku dot com>]

bgat@billgatliff.com wrote:
> 
> Kevin:
> 
> >  The workaround is to preinstall the target headers into
> > '$prefix/$target/include' and then symlinking the
> > '$prefix/$target/sys-include' into it.
> 
> I would even skip the symlinking part.
> 
> The --with-headers= option creates a real mess, as Kai points out.
> Don't use it, simply put the headers in $prefix/$target/include before
> you get started to avoid headaches.

 Currently there is that problem with the 'limits.h'. If the target headers
are seen only in '$prefix/$target/include', the GCC-build doesn't set the
GCC_INCLUDE_DIR/limits.h --> GCC_INCLUDE_DIR/syslimits.h --> (limits.h in
the standard headers) - chain ok... Someone noted this happening with the
'arm-linux' target and it happens with all targets having their own
'limits.h' and 'fixincludes' not seeing it during the build...

 This has been a known problem and I had simply edited the GCC's 'limits.h'
manually while renaming the 'stddef.h', 'stdarg.h' and 'varargs.h' in the
same directory (it the target headers already had them) after the GCC
install. Preinstalling or already having the headers in
$prefix/$target/include (when updating GCC), and not having them visible
in $prefix/$target/sys-include had simply caused that 'fixincludes' didn't
see them... 

 If enabling the 'fixincludes' to see the target headers (using the symlink
or something), one would expect the 'fixincludes' to fix the 'stddef.h' etc.
headers so that they could replace the targets own ones, but whether this
happens or not is unclear for me (because I hadn't enabled the header-fixing).
When the targets own 'stddef.h'...'varargs.h' were found first during the
GCC build because of the '-I$(build_tooldir)/include' used in the
'TARGET_CFLAGS' (or something) in the main Makefile, assuming
them being right also after the GCC installation and disabling the GCC's
own headers with these names, has seemed to be the right thing...

 Ok, using the right kind of 'limits.h' and possibly fixing the GCC's own
'stddef.h', 'stdarg.h' and 'varargs.h' for the target, or fixing the targets
own headers with these names for GCC, are the things which don't happen if
fixincludes doesn't 'see' the target headers...

 If the 'fixincludes' sees the target headers, it isn't sure that it does
all things right. Fixing the Linux kernel headers and installing the fixed
ones into the GCC_INCLUDE_DIR is one thing which doesn't seem to be right.
Letting the 'fixincludes' to do its job and checking the results in
'gcc/include' during the build or in GCC_INCLUDE_DIR after the install may
be the only way.

 From the age when the GCC build still searched the headers to-fix from
'$prefix/$target/include', I have bad experiences about all the stupid things
the fixincludes could do when 'fixing the headers'. So not letting the
'fixincludes' to do its job by changing the search directory elsewhere,
and letting people to put all those miscellanous 3rd party headers there,
was one of the theories I invented in my head when trying to understand
why the change was done by the GCC developers... There had to be some
sane reason... The newlib and glibc coming more and more common as the
target C-library and their headers not needing any fixing, could have been
one sane reason...

 I did a bug report about this subject (changing the search dir for
fixincludes for a cross-compiler), but haven't seen any feedback yet...

 As the 'limits.h' case shows, it is still necessary that the GCC build
scripts still 'see' the target headers. The 'fixincludes' does some things
right, but may do some things wrong, so using 'diff' between the original
and fixed headers is my advice... If the sanity of some fix is
questionable, asking about it here is always possible.

 Those who have used the '--with-headers=' and got the target headers
fixed, could do some kind of check in the GCC_INCLUDE_DIR... I wouldn't
expect any horror stories but some minor bugs surely exists with some
targets... Anyway the fact that the GCC build tries to fix the target
headers from somewhere and then installs the fixed ones into the
GCC_INCLUDE_DIR ($prefix/lib/gcc-lib/$target/$version/include), should
be known by every cross-gcc builder... I would assume this being said
in Bill's FAQ.

 Mostly the discussion here has been about the resulted 'xgcc' (meaning
'cpp0' now) not finding the target headers during the build, the
'fixincludes'-issue hasn't been mentioned so much...

Cheers, Kai



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