Cross compiling according to instructions didn\'t work

[whit]

Figured ntp would be useful to set the errant clock from a server, but following the instructions on pdaXrom.org to the letter (copying and pasting) produces, for instance, an ntpdate binary that won\'t run on the Z, but will run on the AMD.

Are the steps approximate, and in practice different for every program, or has some detail been left out of the instructions?

[CoreyC]

Try to copy/paste this instead of the ./configure command on the tutorial:

CC=armv5tel-cacko-linux-gcc LDFLAGS=\"-Wl,-rpath-link,$X11LIB\" ./configure --host=armv5tel-cacko-linux --build=i686-linux --x-includes=$X11INC --x-libraries=$X11LIB

Nothing is wrong with the tutorial, other than some missing spaces in the ./configure command.

[whit]

Thanks.

That fails in this case. Maybe the code just isn\'t ARM-compatible?

Code: [Select]

/usr/include/bits/mathinline.h: In function `atan2\':

/usr/include/bits/mathinline.h:426: error: unknown register name `st(1)\' in `asm\'

/usr/include/bits/mathinline.h: In function `atan2f\':

/usr/include/bits/mathinline.h:426: error: unknown register name `st(1)\' in `asm\'

/usr/include/bits/mathinline.h: In function `atan2l\':

/usr/include/bits/mathinline.h:426: error: unknown register name `st(1)\' in `asm\'

/usr/include/bits/mathinline.h: In function `__atan2l\':

/usr/include/bits/mathinline.h:427: error: unknown register name `st(1)\' in `asm\'

/usr/include/bits/mathinline.h: In function `fmod\':

/usr/include/bits/mathinline.h:430: error: unknown register name `ax\' in `asm\'

/usr/include/bits/mathinline.h: In function `fmodf\':

/usr/include/bits/mathinline.h:430: error: unknown register name `ax\' in `asm\'

/usr/include/bits/mathinline.h: In function `fmodl\':

/usr/include/bits/mathinline.h:430: error: unknown register name `ax\' in `asm\'

/usr/include/bits/mathinline.h: In function `atan\':

/usr/include/bits/mathinline.h:469: error: unknown register name `st(1)\' in `asm\'

/usr/include/bits/mathinline.h: In function `atanf\':

/usr/include/bits/mathinline.h:469: error: unknown register name `st(1)\' in `asm\'

/usr/include/bits/mathinline.h: In function `atanl\':

/usr/include/bits/mathinline.h:469: error: unknown register name `st(1)\' in `asm\'

make[2]: *** [a_md5encrypt.o] Error 1

make[2]: Leaving directory `/opt/arm/ntp-4.2.0/libntp\'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/opt/arm/ntp-4.2.0\'

make: *** [all] Error 2

[cmisip]

There is an ntpdate binary available for the arm already.  I am using it to update the zaurus clock whenever I put the z on the cradle.  The ntpdate ipk is at :  http://www.geocities.co.jp/SiliconValley-B...0/download.html

[lardman]

Looking briefly at your code snippet, I see the words \'asm\'. My understanding is that this is assembly code and I wouldn\'t be surprised if it didn\'t work assuming it was written for an x86 processor.


Si

[Mickeyl]

It\'s reading from your local (x86) include files. Submit a proper include path.

[Zumi]

Hi!

I tried to compile mutt and fvwm for the Zaurus. The configures of both programs give this error message:

Code: [Select]

checking for ... configure: error: cannot run test program while cross compiling

I tried to comment out these test lines in the configure script but it has a lot similar tests and I don\'t think this is the good way of doing it...

So far I wasn\'t able to compile a single app; but I\'m eager to compile some useful apps, test them and contibute to the project... =)

So. please. help.
Zumi

[lardman]

Your method is the way I do it. But make sure you set the value of the variable after you\'ve commented it out (otherwise configure will get confused at the end).

It is probably easier to do a native compile, but I still stick to cross-compiling (most of my configure scripts only need one or two changes).


Si

[Zumi]

OK, thanks for the reply!
I try to compile it on my Z with gentooforzaurus...

I hope I will have more success.

[Zumi]

Woohoo. I successfully compiled xkbd, made an ipk from it, installed and... I was able to run it.
Nothing can stop me now.

I\'m going to compile more packages; and if I\'m sure what I\'m doing and I know I\'m doing it right, I try to upload them to the unstable feed...

[whit]

Nothing is wrong with the tutorial, other than some missing spaces in the ./configure command.

Corey -

Checked the spaces in the ./configure command, and there were none missing in how I pasted it (this from bash history):

\"./configure --host=armv5tel-cacko-linux --build=i686-linux --x-includes=/opt/arm/3.3.2/armv5tel-cacko-linux/X11R6/include --x-libraries=/opt/arm/3.3.2/armv5tel-cacko-linux/X11R6/lib --disable-debug --prefix=/usr/local\"

So it\'s probably an incompatibility with the ntp files - that running it with the tutorial version produces i686 code instead, and your revised version bombs on the build. I trust most stuff probably builds fine either way; but have no experience in cross compiling from which to sort out what ntp\'s problem may be.

The first time around I also tried the tutorial\'s ipkg building instructions, which also failed (the stuff installed to the PCs directotories instead) - again probably a problem in the ntp distribution\'s files.

[whit]

There is an ntpdate binary available for the arm already. \'

Cool. Thanks!

[whit]

It\'s reading from your local (x86) include files. Submit a proper include path.

Odd about that, since in the enviroment there\'s:

Code: [Select]

X11DIR=/opt/arm/3.3.2/armv5tel-cacko-linux/X11R6

X11INC=/opt/arm/3.3.2/armv5tel-cacko-linux/X11R6/include

X11LIB=/opt/arm/3.3.2/armv5tel-cacko-linux/X11R6/lib

and the configuration was accomplished with:

Code: [Select]

CC=armv5tel-cacko-linux-gcc LDFLAGS="-Wl,-rpath-link,$X11LIB" ./configure --host=armv5tel-cacko-linux --build=i686-linux --x-includes=$X11INC --x-libraries=$X11LIB

- which should have set those. Maybe ntp\'s routines hard-coded some of the includes rather than following standards.

[whit]

There is an ntpdate binary available for the arm already. \'

Cool. Thanks!

Oops! Running that once put the system on suspend, but it came back up with the On button and showed a change in time at the lower right (not yet the right time, but at least different). Running it a second time crashed the system - had to do a battery-removal reset. You\'re using this on pdaXrom?

It does work before bringing up X without ill effect, so it\'s useful on cold boot. And now it works in X in an aterm without crashing things. Wonder what that crash was about? Hmm.

Later: Put system in suspend. Woke it up 15 minutes later - date had gone back to that old Dec 31, 93. Started Firefox. Then ran ntpdate in an aterm - it suspended the system again. Hit On. Tried ntpdate again (it had run the first time in addition to setting the system to suspend), and it froze the system again. This time On brings back the video, but everything\'s frozen up solid.

Is there a function-key combo to drop out of X to a terminal rather than reboot on these freezes?

Is this ntpdate problem likely to be that the version I\'m using is compiled against the wrong libraries, or something deeper?

Later still: ntpdate definitely doesn\'t work once X is invoked. Think it might be a conflict with the lame clock app that can\'t even hold the date through a suspend anyhow. Where do I find the config file to remove that from the system?

& later: It\'s not the clock applet - kill that first and ntpdate still creates trouble. \"killall openbox\" by the way is one way to drop back to the prompt - from which ntpdate works fine again. Are other ttys available while openbox is running? By what hotkeys?

[cmisip]

Sorry, I am using ntpdate with zynergy ROM.  I figured that because it is a terminal app, not an X app, that it should work for you too.  Apparently not.