Compiles great

[gretchen]

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.

Code: [Select]

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.

[blakeyez]

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

[gretchen]

Code: [Select]

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.

[blakeyez]

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

[gretchen]

- 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

Code: [Select]

checking for gcc... (cached) gcc
It does that even if I

Code: [Select]

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?

[blakeyez]

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

[Zumi]

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

[pgas]

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.

[gretchen]

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.

Code: [Select]

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

[blakeyez]

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

[gretchen]

Sounds like a good idea.  I just found out my Zaurus will be here this afternoon                and the native compiling sounds much easier.

[Zumi]

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

[blakeyez]

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

[Zumi]

coreutils-base_5.2.1_armv5tel.ipk includes:

Code: [Select]

[         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:

Code: [Select]

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

[blakeyez]

Hmm ok I stand corrected

Dave