Subject: GCC 2.95 make error

From: Francois Desloges <[email-masked]>
Date: Fri, 17 Sep 1999 16:34:51 -0400

Am I surprised?

I got this error after 6 minutes of compilation building gcc-2.95.1:

make[3]: Entering directory `/usr/src/gcc-2.95.1/gcc'
rm -f tmplibgcc2.a
for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3 _ashldi3_ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf _floatdisf
 _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi _fixunssfdi _fixsfdi _fixxfdi _fix
unsxfdi _floatdixf _fixunsxfsi _fixtfdi _fixunstfdi _floatditf __gcc_bcmp _varar
do \
  echo ${name}; \
  /usr/src/gcc-2.95.1/gcc/xgcc -B/usr/src/gcc-2.95.1/gcc/ -B/usr/arm-linux/bin/
-I/usr/arm-linux/include -O2  -DCROSS_COMPILE -DIN_GCC     -g -O2 -I./include  -fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED    -I. -I. -I./config -I./../include -c -DL${name} \
       ./libgcc2.c -o ${name}.o; \
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  arm-linux-ar rc tmplibgcc2.a ${name}.o; \
  rm -f ${name}.o; \
done
_muldi3
./libgcc2.c:41: stdlib.h: No such file or directory
./libgcc2.c:42: unistd.h: No such file or directory
make[3]: *** [libgcc2.a] Error 1
make[3]: Leaving directory `/usr/src/gcc-2.95.1/gcc'
make[2]: *** [stmp-multilib-sub] Error 2
make[2]: Leaving directory `/usr/src/gcc-2.95.1/gcc'
make[1]: *** [stmp-multilib] Error 1
make[1]: Leaving directory `/usr/src/gcc-2.95.1/gcc'
make: *** [all-gcc] Error 2

I did the 
cp -a /usr/src/linux-2.2.10/include/asm-arm /usr/arm-linux/include/asm 
cp -a /usr/src/linux-2.2.10/include/linux /usr/arm-linux/include/linux
with a freshly patch kernel as recommended by Chris Rutter in its
http://inkvine.fluff.org/~chris/arm-tools.html guide
I use binutils 2.9.5.0.11 and had
-Took gcc-2.95.1
-Applied Philip's 2.95-diff-990730 patch
-Changed #if 0 to #if 1 in gcc/config/arm/linux-elf.h
-Applied the E-Mailed by Philip gcc/fold-const.c patch by hand

Anybody have an idea ?

--
François Desloges
[email-masked]
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Sat, 18 Sep 1999 00:01:51 +0100

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

---

From: Francois Desloges <[email-masked]>
Date: Mon, 20 Sep 1999 11:08:52 -0400

> appropriate places (see the archives).  Or if you're building a cross-compiler

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-masked]
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Mon, 20 Sep 1999 18:46:20 +0100

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

Oops.  The notes on my web page did use to describe this problem but I removed 
that section some time ago thinking Chris had covered it.  Oh well.

>On my Intel-Linux system, as on Dan Jakubiec's one, if I remember:

Yes, that's right.  But that header is part of the C library and so is not 
available until you install libc.

>the "inhibit_libc", --disable-threads, etc.?

This is the correct way to solve the problem.

p.

---

From: Chris Rutter <[email-masked]>
Date: Tue, 21 Sep 1999 23:44:57 +0100 (BST)

> stdlib.h stands, only the linux and asm ones, I think (from Marco Pantaleoni): 

Okay, sorry guv.  There will be, er, a new version of this document
availble soon from a different site, with all these heinous bugs
fixed.  Honestly, when I wrote it, that's what I think it was
suggested I put.

And, you're right, I don't talk about that in the guide; I meant to
patch it in.  I will do soon.

-- 
Chris <[email-masked]>                         ( http://www.fluff.org/chris )