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

[jimk at scitechsoft dot com]

Hey,
I now actually have a working crosscompiler targeting linux!!!

Quick answer to your question, I only had to sacrafice one mammal.

Seriously though, I think you're using the wrong headers as David 
said.  I grabbed the headers off the linux machine in the /usr/include 
directory, and both of those headers should be in that directory.  
That was what I needed to actually build the compiler. Then when I 
got to compiling a test program, I had to grab the libraries off the 
linux machine in both the /usr/lib and the /lib directories.  The libs 
from /usr/lib went in $prefix/i486-linux (or whatever your target is) 
and the libs from /lib went in place of /lib on your host.  At that point, 
I also got 2 missing lib warnings for libraries that it was looking in the 
wrong place for.  I found one in $prefix/i486-linux when it wanted it 
in /lib and one the other way around.  I just created a sym-link for 
each one and tada, successful compile.  Does anybody have any 
idea where I should be putting these libs so I won't have to add those 
2 sym-links?

Thanks, and hth.

-Jim

On 25 Apr 2001, at 16:37, David Korn wrote:

> >-----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
> 
> 



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