View previous topic :: View next topic |
Author |
Message |
roarinelk Guru
Joined: 04 Mar 2004 Posts: 520
|
Posted: Wed Nov 08, 2006 3:38 pm Post subject: [SOLVED] MIPS libs/gcc woes |
|
|
I have a compile problem with native gcc-4.1.1/glibc-2.[45] on mipsel:
Following test code:
Code: |
#include <limits.h>
int main()
{
int i = LINE_MAX, x[PATH_MAX];
return 0;
}
|
compiled on my mips32 environment:
Code: | mipsel-unknown-linux-gnu-gcc test.c
test.c: In function 'main':
test.c:5: error: 'LINE_MAX' undeclared (first use in this function)
test.c:5: error: (Each undeclared identifier is reported only once
test.c:5: error: for each function it appears in.)
test.c:5: error: 'PATH_MAX' undeclared (first use in this function) |
Problem is GCC does not include glibc "limit.h":
Code: | mipsel-unknown-linux-gnu-gcc -O0 -mips32 -E test.c
# 1 "test.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "test.c"
# 1 "/usr/lib/gcc/mipsel-unknown-linux-gnu/4.1.1/include/limits.h" 1 3 4
# 2 "test.c" 2
int main()
{
int i = LINE_MAX, x[PATH_MAX];
return 0;
}
|
The cross compiler on x86 includes a whole lot of other limit.h files and
this little program compiles.
gcc-4.1.1, glibc-2.4, 2.5. Both gcc and glibc on the mips target have been
built by portage on x86 via this call
Code: | ROOT=/var/chroot/mips CTARGET=mipsel-unknown-linux-gnu CHOST=mipsel-unknown-linux-gnu CFLAGS="-O2" emerge -b gcc glibc |
Unfortunately I cannot emerge them on the target itself because in both cases the kernel kills
the build process due to OOM (despite having 128MB of RAM...)
Does anyone know if I can work around this problem?
Thanks!
Last edited by roarinelk on Thu Nov 09, 2006 2:52 pm; edited 1 time in total |
|
Back to top |
|
|
Redhatter Retired Dev
Joined: 20 Sep 2003 Posts: 548 Location: Brisbane, QLD, Australia
|
Posted: Thu Nov 09, 2006 1:42 pm Post subject: |
|
|
Sounds like an artifact from crossbuilding gcc and glibc.
Code: | stuartl@moosehead ~ $ cat > test.c
#include <limits.h>
int main()
{
int i = LINE_MAX, x[PATH_MAX];
return 0;
}
stuartl@moosehead ~ $ gcc test.c
stuartl@moosehead ~ $ gcc --version
gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
stuartl@moosehead ~ $ uname -a
Linux moosehead 2.6.19-rc5-o2 #1 Thu Nov 9 18:12:36 EST 2006 mips64 R5000 V2.1 FPU V1.0 GNU/Linux |
That said... 128MB RAM should be enough ... both my O2 (above), and my Qube2, run fine on 128MB RAM. On the latter, I produce stage tarballs. It takes a good fortnight to compile builds, but it gets there eventually.
How much swap space are you allocating, and how many other apps do you have running? _________________ Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...
Gentoo/MIPS Cobalt developer, Mozilla herd member. |
|
Back to top |
|
|
roarinelk Guru
Joined: 04 Mar 2004 Posts: 520
|
Posted: Thu Nov 09, 2006 2:43 pm Post subject: |
|
|
Redhatter wrote: | Sounds like an artifact from crossbuilding gcc and glibc.
|
I think so too.
Redhatter wrote: |
That said... 128MB RAM should be enough ... both my O2 (above), and my Qube2, run fine on 128MB RAM. On the latter, I produce stage tarballs. It takes a good fortnight to compile builds, but it gets there eventually.
How much swap space are you allocating, and how many other apps do you have running? |
"No swap" was a problem.
I wrote a PCMCIA socket driver, built a kernel with swap support
and now use a 256 MB CF card as swapspace. I was able to compile
glibc-2.5 just fine this way (~5 hours compile time on this 500MHz cpu).
However, GCC-4.1.1 still won't compile ("SSIZE_MAX" undefined in linux-host.c)
I'm going to manually patch the offending files and let it run overnight.
Thank you for your answer! |
|
Back to top |
|
|
roarinelk Guru
Joined: 04 Mar 2004 Posts: 520
|
Posted: Thu Nov 09, 2006 2:52 pm Post subject: |
|
|
roarinelk wrote: |
However, GCC-4.1.1 still won't compile ("SSIZE_MAX" undefined in linux-host.c)
I'm going to manually patch the offending files and let it run overnight.
|
Ha, I should have thought of this sooner:
Copied the cross-gcc's /usr/lib/gcc/mipsel-.../include/limits.h over to the target
and now the little test prog compiles without a hitch... |
|
Back to top |
|
|
SpanKY Developer
Joined: 18 Apr 2002 Posts: 321 Location: Somerville, MA
|
Posted: Fri Nov 10, 2006 12:55 am Post subject: |
|
|
a missing limits.h file almost always means you built the cross-compiler incorrectly ... this is a very common problem |
|
Back to top |
|
|
roarinelk Guru
Joined: 04 Mar 2004 Posts: 520
|
Posted: Fri Nov 10, 2006 5:48 am Post subject: |
|
|
SpanKY wrote: | a missing limits.h file almost always means you built the cross-compiler incorrectly ... this is a very common problem |
The file wasn't missing, just different.
The native SH-4 compiler built with the above mentioned command works flawlessly so far.
I even compiled a working Xorg7.1 ;) |
|
Back to top |
|
|
SpanKY Developer
Joined: 18 Apr 2002 Posts: 321 Location: Somerville, MA
|
Posted: Fri Nov 10, 2006 6:06 am Post subject: |
|
|
also a clue that the compiler isnt quite right
a proper limits.h should have an include_next at the bottom ... it is common to end up with one that lacks the include_next because during the build, gcc was not given proper system include paths |
|
Back to top |
|
|
roarinelk Guru
Joined: 04 Mar 2004 Posts: 520
|
Posted: Fri Nov 10, 2006 6:22 am Post subject: |
|
|
SpanKY wrote: | also a clue that the compiler isnt quite right
a proper limits.h should have an include_next at the bottom ... it is common to end up with one that lacks the include_next because during the build, gcc was not given proper system include paths |
Yes you are right. The old one is missing the #include_next<> at the end.
(And to correct myself: the SH4 compiler _was_ built on the target since "make install" fails when cross-compiling.
I could not build gcc natively on mips initially since the gcc in the available mips-le stages segfaults a LOT
on au1200. All better now.)
Learned something new today, Thanks! |
|
Back to top |
|
|
|