If the configure script is less well behaved (still runs gcc instead of arm-linux-gcc etc), a common trick is PATH=/usr/local/arm-linux/bin:$PATH ./configure --host=...
Installing qemu for i386 host and arm user target together with the corresponding binfmt-misc setup can sometimes successfully run those intermediately generated binaries during configure/compile.
Some programs really cannot be easily configured in a cross-environment. It is useful to keep a native dev-kit around, even it it is for the configure step only.
Rather than starting from generic sources, get the sources from the Debian project that are usually known to compile for arm and may have useful patches applied.
Often something like \'make install DESTDIR=/tmp/root\' works (confirm with -n first) which is very useful to sort things out and discard unwanted parts.
Do not be afraid to patch compiled binaries for trivial things like file paths if that can avoid a long native recompile.
i have tried to run
$ PATH=/usr/local/tools/linux/arm/gcc-3.2.2/arm-linux/bin:$PATH ./configure --host=arm-linux
reating cache ./config.cache
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... yes
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for c++... c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... yes
checking whether we are using GNU C++... yes
it did configure successfully, then i type
$ make
it did make successfully, then i type
$ file \"application_name\"
it showed \"ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped\"
instead of
\" ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
\"
which means the application is run under PC instead of ARM, any ideaS?
