RE: compiling gcc using --with-headers pointing to linux headers

["Conyers, Steve" <steve dot conyers at lmco dot com>]

Dave -- Thanks for your patient explanation.  You'll make a cross compiler
out of me yet!  However, on my Solaris system, /usr/include contains headers
provided by Sun.  When I installed the native gcc, I believe that those
headers were processed by fixincludes (and the results stored elsewhere?)
for use by the native compiler.  I probably don't have both of the two sets
of Linux headers that you so eloquently described.  Searching for stdlib.h
for example beneath linux-2.2.17 draws a blank.  Apparently, the 2.2.17
distribution for linuxppc only contains the "specialized" headers for the
kernel itself and not those for use by a compiler.  If I were to install
linux on my Sun and then install gcc under it, then there would be headers
available for use in building a cross compiler and they would probably be in
/include or /usr/include.  But would they correspond to linux(for
ppc)-2.2.17?  Maybe not.  They would correspond to whatever linux version I
put on the Sun.

Doesn't sound too attractive, but then the (apparently fundamentally
flawed?) process of doing newlib first, then glibc seems to be distasteful
to the most knowledgeable folks out on the mailing list.  Am I missing
something?  (brains, yeah, I already gnu that)  By the way, what does OTOH
stand for?

Regards, Steve Conyers

-----Original Message-----
From: David Korn [mailto:dkorn@pixelpower.com]
Sent: Wednesday, April 25, 2001 8:37 AM
To: 'Conyers, Steve'; 'jimk@scitechsoft.com'
Cc: Crossgcc-List (E-mail)
Subject: RE: compiling gcc using --with-headers pointing to linux
headers


>-----Original Message-----
>From: Conyers, Steve [mailto:steve.conyers@lmco.com]
>Sent: 25 April 2001 15:49

>Yeah, I blasted out all the old newlib stuff.  In fact, out of paranoia I
>wasn't content with a "make distclean" so I even blasted the old sources
>and "re-untarred" them.

  I do that kind of superstitious thing myself quite a lot!  However, I
think that the only time it might actually be important is if you've done
a configure in the Gcc source dir, instead of a separate build dir.

>I think there is a flaw in the --with-headers scheme.  The point where I
>fail in the Makefile is 
>
>/export/home/gnu-source/build-gcc/gcc/xgcc
>-B/export/home/gnu-source/build-gcc/gcc/
>-B/export/home/xc/powerpc-motorola-linux-gnu/bin/
>-I/export/home/xc/powerpc-motorola-linu-gnu/include -O2 (etc, etc)

  There's an x missing in the target name here.  linu-gnu ?  I expect this
is just an error in transcription or transmission, but if that is really
what the output from gcc said, then there must be something *very* wrong.

>../../gcc-2.95.2/gcc/libgcc2.c (etc, etc)
> 
>But where NONE of the additional -I's point to
>$target/powerpc-motorola-linux-gnu/sys-include which is where 
>--with-headers does its thing.

  No, that's ok: it's covered by the
-I/export/home/xc/powerpc-motorola-linux-gnu/include flag, because when the
fixincludes process runs, it takes the originals from
$prefix/$target/sys-include and copies them into $prefix/$target/include,
fixing them as it goes!  So they should be found there.

>  In the newlib case I was able to work around this by creating a symbolic
> link 
>#ln -s sys-include include
>in the $target/powerpc-eabi directory.

  This only worked because newlib headers don't get fixed!  Otherwise there
would have been clashes when the fixincs process tried to read the
$p/$t/sys-include/ file and write the $p/$t/include/ version at the same
time, since they are one and the same file in that case!

>  This workaround didn't work when I naively configured for gcc using
>--with-headers=/export/home/linux-source/linux-2.2.17/include
>
>The linux headers got copied over, but there was no stdlib.h anywhere to be
>found in linux-2.2.17.  This seems quite peculiar.  Could it be that I need
>to do a make on it using my native gcc to "flesh it out" header-wise before
>using its headers for the cross compiler build???

  Nope.  I *believe* (but not having a Linux system to check this up on I
cannot *promise*) that you've chosen the wrong set of the two sets of Linux
headers.  The what !?!?!  Yep, I said two sets of Linux headers.  One is 
part of the kernel source - that looks like the one you've mentioned above
 - and one is there for the user's compiler - and that's the one you should
be using.

  The kernel source headers are very specialized, and designed for the
compilation of the kernel itself, which obviously enough runs without any
C library (after all, it provides the actual syscalls that the libc has to
invoke to perform the functions of things like stdio.)  So they don't define
all the standard library stuff, and that's why there was no stdlib.h!

  The user headers OTOH are the straightforward headers that explain the
C library's contents and datatypes, and it's that which is what Gcc wants
to know about when it compiles libgcc for the cross target.  I'm not sure
where they live, but it will be either /include or /usr/include; have a
look in /usr/include first.  Whereever they turn out to be when you find
them (a good way would be to look at the output given by gcc -print-search-
dirs with your native compiler), that is the argument you must give to 
--with-includes.

     hth,
       DaveK
-- 
 All your base are belong to the Israeli army!  Oh, now they aren't again!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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