OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: gretchen on November 02, 2004, 06:41:35 pm
-
I have a C860 on it's way to me at this very moment!!!!!
While I wait I've decided to compile some packages that I haven't seen offered and would like. I don't know how to program (beyond some very basics) but I have compiled software for my desktop linux box. I may be way over my head here.
I decided to start with mutt. Following the SDK tutorial works great, I can configure it, make and make install without any errors. I've been copying and pasting from the tutorial. It's when I get to the stripping that it hiccups.
sh-2.05a# armv5tel-linux-strip ipkg_tmp/usr/local/bin/*
armv5tel-linux-strip: ipkg_tmp/usr/local/bin/flea: File format not recognized
armv5tel-linux-strip: Unable to recognise the format of the input file ipkg_tmp/usr/local/bin/mutt
sh-2.05a#Is this something I need to worry about? The mutt executable is about 2MB and it seems like it should be able to be smaller. As far as flea goes, it's for bug reporting in mutt and I think I should just be able to leave that out as it's not necessary.
I'm doing this from a chrooted jail because I was worried that I might mess up my main installation. (I realize now that it is very safe.) I'm using the RC5 SDK.
Is there an easy fix? Does the stripping really matter?
If I ignore it and continue I have problems with mkipkg but I think that's a seperate issue.
-
Try running 'file' on those binaries - make sure they're ARM executables. If they're not, that would be the reason for strip bailing.
Dave
-
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
Doesn't look like arm to me........now to figure out what I'm doing wrong...I know you all are busy but if I could get a nudge in the right direction? I followed the SDK tutorial to a T....I think, I'll be going over it again just to make sure.
-
OK... Things to make sure of:
- You extracted the SDK in the root directory; you should end up with /opt/arm/3.3.2-vfp
- You have to execute /opt/arm/runzgcc-vfp.sh to setup your path, etc, appropriately
- Make sure to specify --host=armv5tel-cacko-linux when you run the configure script for the package you're building
- Check that it finds armv5tel-cacko-linux-gcc as the compiler (watch near the beginning of the configure process, as well as during the build)
Dave
-
- SDK extracted correctly--check
- rungcc-vfp.sh--check
- host set correctly--check
I'm pretty sure that the problem is that it's still being compiled with the normal gcc. In the results from ./configure --all extra stuff
checking for gcc... (cached) gcc
It does that even if I export CC=/opt/arm/3.3.2-vfp/bin/armv5tel-cacko-linux-gcc
What's the (cached) thing about? Is that what's causing the problem?
-
Do a 'make distclean' - that should remove any configure cache lying around - and yes, that's what's doing it. Make sure that the file config.cache disappears.
Dave
-
I had the same experience with crosscompiling: things compiled for x86. I think that configure line in the SDK tutorial doesn't really tells the automake system to compile it agains arm. I really haven't gone in the topic deeply after two or three try, because now I'm compiling with the native SDK. It would be good to know how to eliminate this problem, because compiling big programs on my Z is painful...
Zumi
-
The problem is most probably that the config file for the input files for automake autoconf etc... are not taking cross-compilation into account for the program you compile.
Unfortunately I don't think there are some magic parameters to give to the configure script to make it allways work...but some tweakings...(maybe somebody who masters autoconf and such can give some precise instructions for making it cross-compile friendly though)
A solution might also be to report the problems to developer of the app you try to compile, and explain your trouble so that they can fix whatever needs to be fixed and include this in their future releases.
-
Do a 'make distclean' - that should remove any configure cache lying around - and yes, that's what's doing it. Make sure that the file config.cache disappears.
Thank you so much! It's now using the correct compiler. However it created another problem.
checking size of int... configure: error: can not run test program while cross compilingI'm guessing I need to pass something else to configure, or edit some file...
-
AFAIK, the only real way to bypass that problem is to 'hack up' the configure script to give it proper values when it can't run the test program. However, in cases like this, I have always moved on to building with the native compiler on the zaurus, as it becomes a HUGE pain to deal with when cross-compiling.
However, if you DO move to the native development environment, I definitely suggest the use of distcc. Since you already have the cross environment setup on your desktop, simply install distcc, and from within your x-compilie env (ie: after running runzgcc.sh), run the distccd server. Make sure to link gcc, cc, g++ and c++ to their arm-linux-* counterparts in /opt/arm/3.3.2-vfp/bin. That way, distcc will use the proper compilers.
On the zaurus side, you need to install the distcc package from the rc5 feed, then make a new directory anywhere that will contain links for gcc, cc and c++ (don't THINK I'm missing anything here, but I could be...) to /opt/sdk/bin/distcc. Add that new directory to the beginning of your path, set your DISTCC_HOSTS, and off you go Compiling is at least 5 times faster, I've found, using distcc on the zaurus than just having the z compile by itself.
Dave
-
Sounds like a good idea. I just found out my Zaurus will be here this afternoon and the native compiling sounds much easier.
-
For your information: I compiled and uploaded the GNU grep to the unstable feed. (because Busybox grep sucks and an app I'm compiling needed it)
I posted this here because I think most of the compiler guys read this topic.
Zumi
-
Erm, why not just install the coreutils package? IIRC that includes the gnu grep binary, along with 'better' binaries for almost all the essential scripting apps.
Dave
-
coreutils-base_5.2.1_armv5tel.ipk includes:
[ chmod cut echo head md5sum mv rmdir sync tr uptime
basename chown dd env kill mkdir od sleep tail true who
cat chroot dirname expr ln mkfifo pwd stty test tty
chgrp cp du false ls mknod rm su touch unameand coreutils-extra_5.2.1_armv5tel.ipk has:
cksum dircolors groups join nohup printenv sha1sum sum uniq whoami
comm expand hostid link paste printf shred tac unlink yes
csplit factor hostname logname pathchk ptx sort tee users
date fmt id nice pinky readlink split tsort vdir
dir fold install nl pr seq stat unexpand wcGrep is missing.
So here's my grep ipk, enjoy!
Zumi
-
Hmm ok I stand corrected
Dave
-
I've just tried distcc and it is as simple as described by blakeyez!
Laze, I vote for this to go to the FAQ!
Thanks blakeyez
-
Not a problem Distcc comes in handy in many slow-compile situations... Things like building linux-from-scratch, etc. Especially on old hardware.
Dave