Peter Eisentraut <peter_e@gmx.net> writes:
> More importantly, you *should* *not* do these tests in configure because
> these tests will be unreliable in a cross-compilation situation.
> Cross-compilation in this context does not only mean compiling between
> completely different platforms, but it includes any setup where the build
> system is configured differently from the system you're going to run the
> system on, including building on a noexec file system, misconfigured
> run-time linkers, different user id, or just a different file system
> layout on an otherwise identical platform.
An approach I've followed in the past is to use three-way logic. If
configuring for a native system, compile and run a program which
provides a yes or no answer. When using cross-configuration, set the
configuration variable to ``don't know'' (or, since this a database
group, NULL).
Pull all code which needs to make this test into a single routine.
Let it check the configuration variable. If the variable is ``don't
know,'' then compile in a static variable, and run the required test
once, at run time, and set the static variable accordingly. Then test
the static variable in all future calls.
This is the approach I used in my UUCP code to look for a bad version
of ftime on some versions of SCO Unix--the ftime result would
sometimes run backward.
Ian
Co-author of GNU Autoconf, Automake, and Libtool