OESF Portables Forum
Everything Else => Zaurus - Everything Development => Distros, Development, and Model Specific Forums => Archived Forums => OpenZaurus/Opie/Qtopia => Topic started by: summer00 on June 06, 2004, 11:55:15 pm
-
i have read a lot of articles regarding to cross compiling, but most of them only touches on cross compile some simple .cpp programs.....using tmake , gcc -o and etc.....
i wonder how to cross compile some softwares that we normally compile using ./configure-]make install under linux ....zany ideas? thanks a lot
p/s: IM USING REDHAT LINUX 9 KERNEL 2.4.26
thanks in advance
-
Source your dev-arm-qpe.sh script, then in the same terminal window do something like:
./configure --host=arm-linux
then \'make\'
You may run into issues with both the configure and the make processes if intermediate binaries are produced and used in the process. These are normally pretty easy to sort out. I generally take the code snippet in question, cross compile it, copy it across and run, then edit the configure script according to the answer. If it happens in the make process, then I just open a seperate window (in which I\'ve not sourced dev-am-qpe.sh, copy the command in quesiton over, then run make again in the main window.
Actually I\'ve already written all of this in the Linux Applications bit of the forum, under a topic called something like \'Gcc 3.x\'. There\'s probably some more info in there.
Let me know how you get on.
Si
P.S. make install is a problem, I do:
make -n install ] make_install.out,
then install by hand from there. There are have been other suggestions (another topic of mine, in Request for Applications called \'make install\' I think.)
-
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.
-
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=...
This is actually part of what sourcing dev-arm-qpe.sh does.
Si
-
i have tried below:
source dev-arm -qpe.sh
./configure --host=arm-linux
it stoped when reached here:
checking location of Qt library...
not found. Giving up.
i have !Qtopia installed in : opt/Qtopia
any ideas? thanks
-
The best way to compile such programs is on Zaurus itself. Use dev-img 1.5 (available in ZUG downloads). Note that not all Qtopia can be compiled with this dev-img since it\'s missing a UIC tool.
-
actually i was compiling c++ .....can this \"gcc-cross-sa1100-2.95.2-0.i386.rpm\" be used to compile c++ ??
do i need to install the arm-linux-g++ package as well ? cuz in
file:/opt/Embedix/tools/lib , there is only a directory \"gcc-lib\" but not \"g++-lib\"
-
actually i was compiling c++ .....can this \"gcc-cross-sa1100-2.95.2-0.i386.rpm\" be used to compile c++ ??
do i need to install the arm-linux-g++ package as well ? cuz in
file:/opt/Embedix/tools/lib , there is only a directory \"gcc-lib\" but not \"g++-lib\"
Yes, C++ programs also compile
-
Generally you need to have QTDIR set for the target - /opt/Qtopia maybe, or /home/QtPalmtop for native, or maybe even somewhere else for cross compiling. Generally config.log, or searching the ./configure script for the offending error message and patching the failing test (or figuring out what it is looking for) helps.
./configure is one of the most evil things left in opensource. Worse are the ones that will rerun themselves in a specific shell, so you can\'t do things like \"sh -x ./configure\" to see where the problem is. Second place is libtool.
I think you can compile uic for a native development, but I haven\'t tried. moc works though.
-
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?
-
It probably won\'t run though. The cross-compiler has produced the object code but your x86 linker has linked it as you didn\'t set the correct env vars (I think).
Try it and see.
Si
-
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=...
...
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?
If you configure with
PATH=/usr/local/tools/linux/arm/gcc-3.2.2/arm-linux/bin:$PATH ./configure --host=arm-linux
you must make with
PATH=/usr/local/tools/linux/arm/gcc-3.2.2/arm-linux/bin:$PATH make
or it will not work for obvious reasons. Sorry not to have included this above.
I has nothing to do with environment variables (other than PATH). A properly configured compiler (cross or native) does not need any environment variables to be set.
-
I have had no problem cross-compiling with configure scripts by doing the following:
1) Follow this howto: http://www.zaurususergroup.com/modules.php...ompiler%20Setup (http://www.zaurususergroup.com/modules.php?op=modload&name=phpWiki&file=index&pagename=Compiler%20Setup) (It\'s useful to do all the steps just to prove the cross compiler is working)
2) source dev-arm-qpe.sh
3) CC=arm-linux-gcc ./configure --target=arm-linux
4) make
-
You should however be careful using --target, this is more often used when you\'re trying to create a cross-compiler (and it will fail for some configure scripts if this is not what you\'re doing).
You really ought to use --host (rather than --build and --target)
Simon
-
thanks everyone ,finally i was able to compile using arm-gcc(zazz\'s method), but another problem occur was the compile process stopped with
make[1]: *** No rule to make target `../dissipate2/dissipate2.a\'
may be it is the program problem not the compiler itself, thanks a lot
-
It looks like it is a specific problem with whatever you\'ve compiling. What are you compiling BTW?
Did the configure script finish running?
Si
-
i was trying to cross-compile kphone(an asterisk PBX client) so that it can work on the zaurus 5500, anyone has tried this? ya the configure script did finish running
my problems are :
/usr/lib/qt-3.1/lib/libqt.so: could not read symbols: Invalid operation
/usr/lib/libogg.so: could not read symbols: Invalid operation
under ...../arm-linux/libp, no files named \"libqt.so\" , \"libogg.so\" found ,could it be that i need to install something else ? probably those extra .so files for arm development?
-
Looks like you still haven\'t got your environment setup properly as that looks like your desktop\'s QT libraries.
In any case there is already an Asterisk PBX Zaurus client: http://www.killefiz.de/zaurus/showdetail.php?app=1848 (http://www.killefiz.de/zaurus/showdetail.php?app=1848) (Don\'t know how good it is though)
-
Plus you\'ll need to grab the sources for libogg, cross-compile it, and add it to the appropriate lib directory (and add its headers to include) in the cross-toolchain.
Si