OESF Portables Forum
Everything Else => Zaurus - Everything Development => Distros, Development, and Model Specific Forums => Archived Forums => Linux Applications => Topic started by: rleao on August 26, 2005, 12:36:32 am
-
Hi all,
I've been trying to do some netive compiling in my zaurus (with OZ 3.5.3) and I bumped into errors from the .configure. No. 1, I have automake installed but it does not find it. that's fine but then it says that c compiler cannot find executables:
checking for a BSD compatible install... (cached) $/usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... missing
checking for working autoconf... found
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... missing
checking host system type... armv4l-pc-linux-gnuoldld
checking target system type... armv4l-pc-linux-gnuoldld
checking for gcc... (cached) arm-linux-gcc
checking whether the C compiler (arm-linux-gcc ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.
I have libc6-dev - 2.3.2+cvs20040726-r17, gcc 3.4 and libc6 2.3.2.
I tryed to do a small program as mentioned in other forums, and I've got a similar problem as the forum:
https://www.oesf.org/forums/index.php?showtopic=9242 (https://www.oesf.org/forums/index.php?showtopic=9242):
root@collie:/media/card/src/gbz/gngb-20020111# gcc -o compiletest compiletest.c
/usr/lib/gcc/arm-linux/3.4.3/../../../../arm-linux/bin/ld:/usr/lib/gcc/arm-linux/3.4.3/../../../libc.so: file format not recognized; treating as linker script
/usr/lib/gcc/arm-linux/3.4.3/../../../../arm-linux/bin/ld:/usr/lib/gcc/arm-linux/3.4.3/../../../libc.so:4: syntax error
collect2: ld returned 1 exit status
anyone has any idea in how to fix it and make it usable? Thanks heaps.
-
I have automake installed but it does not find it.
Where is it installed? Is it in $PATH? Have you looked at configure.log to see what the exact test & error was?
checking host system type... armv4l-pc-linux-gnuoldld
Interesting....
Did you make the alteration to libc.so as detailed in the 2nd page of the thread you linked (see here too: http://handhelds.org/moin/moin.cgi/DevelopOnFamiliar) (http://handhelds.org/moin/moin.cgi/DevelopOnFamiliar))?
Si
-
I have just commited a necessary glue package to use a 2.95.3 toolchain in OE. This glue package has been sitting in my tree for a while and I'm using it to build my python distribution for the SharpROM without needing any additional hacks.
To make OE build SharpROM compatible QtE applications, just add two or three dedicated packages, i.e. qte-sharprom and libqpe-sharprom - that should be all.
-
Thanks Lardman!
I actually did but I think when I upgraded the zaurus, I had it undone. But it was a good reminder. My automake is in the path but there is something funny with libperl (when you type automake):
perl: symbol lookup error: /usr/lib/libperl.so.5: undefined symbol: __umodsi3
it just complains now when one compiles about:
arm-linux-gcc: unrecognized option `-wall'
also, when I tried to compile GNU gameboyz it says (make):
arm-linux-gcc: unrecognized option `-wall'
In file included from /usr/include/bits/local_lim.h:36,
from /usr/include/bits/posix1_lim.h:145,
from /usr/include/dirent.h:221,
from rom.c:30:
/usr/include/linux/limits.h:124:26: no include path in which to search for limits.h
rom.c: In function `check_dir':
rom.c:151: error: `ENOENT' undeclared (first use in this function)
rom.c:151: error: (Each undeclared identifier is reported only once
rom.c:151: error: for each function it appears in.)
make[3]: *** [rom.o] Error 1
make[3]: Leaving directory `/media/card/src/gbz/gngb-20020111/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/media/card/src/gbz/gngb-20020111/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/media/card/src/gbz/gngb-20020111'
make: *** [all-recursive-am] Error 2
it first said that no linux/errno.h was found, so I did a symbolic link (/usr/include/linux) to /usr/include.
-
perl: symbol lookup error: /usr/lib/libperl.so.5: undefined symbol: __umodsi3
Is this version of perl from the feed? I imagine it's not.
arm-linux-gcc: unrecognized option `-wall'
Shouldn't it be a capital W as in -Wall ?
/usr/include/linux/limits.h:124:26: no include path in which to search for limits.h
Seems a bit odd that it says that.
rom.c:151: error: `ENOENT' undeclared (first use in this function)
This is the error though: ENOENT is a preprocessor macro defined in include/asm-generic/errno-base.h (from google).
See if you've got that, and see if you can work out why it's not been included/processed/etc.
Si
-
Hi Lardman, i tried about 3 libperls (as the OZ feed does not seem to have one) and all the same. Also, I don't have /usr/include/linux or /usr/include/asm
would you know any pakage that provides these header files?
-
Try running mkcompat on that perl binary then.
I've also just been told that perl in OE builds (v 5.8.7), so you'd be better to build that (or ask hrw to do so in the upgrades thread).
would you know any pakage that provides these header files?
I'm afraid not, though I imagine they are in there somewhere.
If you still can't find them here are some tarballs of mine from my OE setup:
http://people.bath.ac.uk/enpsgp/Zaurus/rom_images/ (http://people.bath.ac.uk/enpsgp/Zaurus/rom_images/)
Note that I am building for a C750, I don't know whether the headers will be different (the arch and asm parts at least).
Si
-
I suspect they are in the linux-libc-headers package, but I haven't checked.
-
Thanks Lardman!!!
It worked beautifully!
Btw, libpthread.so had the same sintax error as libc.
Other thing, would you by any chance know if there is a float point problem with the zaurus sl5500? I am doing some integrations in another program that have exp and stuff and it gets very funny results on the zaurus but not on the pc. But anyway, thank you very much for the includes.
-
Regarding the floating point thing, I wonder if this is something to do with soft-float? How funny are the results?
Does anyone know how the toolchain is told to use soft-float, or is it a built in setting when the toolchain is built> I had a quick look through the log files from my OE builds but couldn't see anything related.
Si
-
I've just spoken to koen on IRC and he said to:
Set TARGET_FPU=soft, check the gcc .incs (where I assume TARGET_FPU will make some changes).
See how you get on with that,
Si
-
I've just spoken to koen on IRC and he said to:
Set TARGET_FPU=soft, check the gcc .incs (where I assume TARGET_FPU will make some changes).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93885\"][{POST_SNAPBACK}][/a][/div]
OZ sets it to soft, causing all softfloat problems. remove TARGET_FPU=soft from openzaurus.conf and build a new image. You'll need a brand new image since it requires a new glibc and thus affects every app
-
I think he wants to produce soft-float binaries to run on his soft-float OZ 3.5.3 'ROM' using a soft-float toolchain (as it came from the OZ feed).
I'd try the TARGET_FPU thing,
Si
-
Don't you have to set this up before compiling arm-linux-gcc (in the gcc conf files) or you can set it elsewhere?
-
well, if anywone wants to see (the program) it:
http://jcsmr.anu.edu.au/~rleao/mntb_qt.tar.gz (http://jcsmr.anu.edu.au/~rleao/mntb_qt.tar.gz)
it calculates ionic conductances in neurons and if one decides to compile, as I put some code in examplebase.cpp and examplebase.h, so if you do a qmake/tmake backup these files before and then after the tmake copy then back to examplebase.cpp and examplebase.h
the results in the zaurus are so bizarre that in the pc, the voltage is -60 if you dont stimulate the neuron (it shows in the graph pad) the same voltage in the zaurus is +18...
anyway, if anyone wants to see it dunno if it's very interesting but I really appreciated all the help.
-
Don't you have to set this up before compiling arm-linux-gcc (in the gcc conf files) or you can set it elsewhere?
I'm not sure, but probably.
I just did a grep -i 'TARGET_FPU' ./* of my OE cross directory and it only found the string in binary files.
If you run 'gcc -v' it should say, at the very end, '--with-float=soft' (that's what my cross-toolchain version says anyway).
Si
-
Sorry if I'm dragging the topic back a bit, or maybe you can redirect me to the right thread, but I'm having the same aclocal and automake issues that started this thread. I've put dev_img-1.5 on a SL-5600 following the steps from
https://www.oesf.org/forums/index.php?showt...=30&#entry94019 (https://www.oesf.org/forums/index.php?showtopic=10201&pid=94019&st=30&#entry94019)
I tried following the libc.so fix from
https://www.oesf.org/forums/index.php?showtopic=9242&st=15 (https://www.oesf.org/forums/index.php?showtopic=9242&st=15)
but on my Z, libc.so is linked to libc.so.6 which itself is a link to libc-2.2.2.so and the "BUG" line is not there. VI won't open any of the linked files
Do I need a different text editor, or am I looking in the wrong place after all, or does dev-img-1.5 not work on SL-5600?
Other particulars:
SharpRom
SL5600 pxa250
WinXP/FC3
Thanks for any help
-
See if these files exist (automake at least) in the cramfs image you're using, make sure you've set $PATH accordingly would be my best guesses.
Si