On Fri, 17 Sep 1999, you wrote:
> >=2E/libgcc2.c:41: stdlib.h: No such file or directory
> >=2E/libgcc2.c:42: unistd.h: No such file or directory
>
> I think Chris Rutter's toolchain guide talks about this. Briefly, you need to
> either provide the headers or use -Dinhibit_libc and --disable-threads in the
> appropriate places (see the archives). Or if you're building a cross-compiler
> you might not care.
>
> p.
Chris Rutter's toolchain guide does _not_ talk about this. I've read it 37
times and knows it by heart (it says as well that we should make gcc from the
gcc subdirectory which causes the famous libiberty/libiberty.a error). The
headers the guide instructions provide don't include the glibc one where
stdlib.h stands, only the linux and asm ones, I think (from Marco Pantaleoni):
>> 3) Finally, I think the reason I hit this problem is that the Linux source
>> base does not contain all the header files I need (such as stdlib.h,
>> unistd.h, etc.). Why are these files not in the Linux kernel source base?
>> Where do they come from?
>
>Kernel code can't rely on libc (ie, you can't call malloc or printf from
>kernel-space). Since the header files you mention are part of libc, and
>can therefore be used only by user-space programs, they can't be distributed
>with kernel sources.
On my Intel-Linux system, as on Dan Jakubiec's one, if I remember:
# locate stdlib.h
/usr/include/stdlib.h
I've found the -Dinhibit_libc etc... solution from Dan Jakubiec and the archive
as well. Thanks a lot.
However from the archive (Philip B. to Dan J.), I've learned that:
>>1) What effect will the "inhibit_libc", "__gthr_posix_h", and
>>"--disable-threads" options have on my compiler?
>
>The generated libraries will not be thread safe. This will bite you if, for
>example, you have a multithreaded C++ program that uses exceptions.
>
>>2) Would it be better to add a "-D/usr/include" instead the the above
>>defines? I am building a gcc cross-compiler for an ARM Linux system on an
>>Intel Linux box. Will the system header files be close enough, or should I
>>not take this chance?
>
>You would probably get away with this most of the time, but it's probably not
>a good idea.
Not being able to support exception in multithreaded C++ program is out of the
question for me. I need a perfectly reliable toolchain.
What if I use option 2 add my actual Intel-Linux "-D/usr/include", build gcc
for arm, build the glibc for arm, and rebuild gcc with the new arm header ?
Why isn't -D/usr/include generally a good idea?
Isn't it a way to include some other directory with the appropriate glibc
header for the arm?
How would I do this and which versions of glibc/header
should I use?
Oh, and by the way if this works where should I put the famous
"-D/usr/include"?
Or what about option 1 ("inhibit_libc", --disable-threads, etc.), and again
build/install glibc for arm, rebuild gcc with the new arm header and whitout
the "inhibit_libc", --disable-threads, etc.?
Thank you for your enllightenments,
--
Fran�ois Desloges
[EMAIL PROTECTED]
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
