I know the question is vague, but I didn't quite know how to express what I'm facing here: I'm trying to cross-compile an implementation of Prolog (particularly SWI-Prolog) from the sources. They use the GNU-Autoconf tools (to which I'm a complete beginner) to build the sources, so I supposed I could set the --host and --build triplets to allow for ARM cross-compilation, but it didn't work. This is the command I issued:
$ ./configure --build=i686-pc-linux-gnu --host=arm-linux-gnueabi
(... lots of checks ...)
checking for clock_gettime in -lrt... yes
checking for clock_gettime... yes
checking for pthread support for cpu clocks... configure: error: in `(...)/pl-6.6.5/src':
configure: error: cannot run test program while cross compiling
See `config.log' for more details
(The complete output is pasted here)
I've checked the config.log file, but I am unable to understand what's exactly missing. I understand that at this stage, there might be several missing libraries or errors, but I'm unable to understand where to start from.
The output of configure says:
checking for pthread support for cpu clocks... configure: error: in `(...)/pl-6.6.5/src':
configure: error: cannot run test program while cross compiling
What this probably means is that somewhere in configure.ac there's a call to the macro AC_TRY_RUN or something like it. This macro basically compiles an executable and executes it, trying to find out more details. Calling this macro won't work when cross compiling, since the build and host architecture differ. From your paste, there seems to be another one that doesn't cause configure to fail:
checking whether mutex support recursive locking... ./configure: line 7307: ./conftest: cannot execute binary file
IMHO package maintainers should be notified that their package won't cross compile (unless they specifically say that it won't in the README or other documentation).
In order to get it to cross compile, you have to figure out the "right" answers of the AC_TRY_RUN tests for your platform and find a way to integrate them into configure.ac, essentially patching configure.ac. The package maintainers might be able to assist with this task also.
I suppose you could also use something like Scratchbox2 if it's available for your device.