Re: [gtk-list] Patch to glib/configure.in

[Tim Janik <timj gtk org>]

On Mon, 15 Feb 1999, Pavel Roskin wrote:

> Hello!
> 
> I'm attaching a patch against configure.in for glib.
> Autoconf produces a lot of warnings while processing this file because
> several AC_TRY_RUN directives don't allow cross-compiling. The
> default (for cross-compiling) behaviour, as specified by autoconf
> documentation should be to use `pessimistic' values, so that the program
> compiles, even if it lacks some features.

hm, we've currently been blatantly ignoring cross compilation issues, mainly
due to two reasons:
- glib contains some *very* system specific code and checks and does some pretty
  clever magic in some cases to detect system requirements.
- glib contains compiler specific code and checks, so it usually has to be
  reconfigured and recompiled even if you just switch compilers.
because of this, cross compilation seems pretty worthless if you don't intend
to install glib on a system that doesn't completely match the build system's
installation.

> It is not possible to fix all such cases. Sometimes it is necessary to ask
> the user to run the test program on the host machine; this is not yet
> implemented in autoconf.

fixing the current AC_TRY_RUN() invokations is actually the minor part of
getting cross compilations to work, glib does header greps and similar things
to figure whether certain functions (facilities) are present, in one case
it even evaluates the default values for static structure initializations
byte by byte.

reading over your changes list, there are at least two cases where we need
definite informations to achive a successfull compilation.

> Following changes have been made:
> 1) While testing for flags enabling ANSI mode, assume no flags are needed.
> It is unbelievable that someone cross-compiles using a K&R compiler.
> 2) While testing for `-std1' flag, add a dummy error to placate autoconf.
> The shell should never get there.
> 3) Pessimistic values for __inline, __inline__ and inline - assume they
> are not supported. Spaces changed to tabs where needed.
> 4) Pessimistic values for va_copy, __va_copy and copy by value - assume
> that none is supported.

a va_copy implementation is vital to glib, at least one possibility *must* be
provided by the target system: va_copy, __va_copy, copy by value or copy as
array.
a pessimistic value would probably be "copy by value", since that seems
to be what most systems support, on the other hand, it might make more sense
to default to the mechanism that is provided by the built system.

> 5) Assume that underscores are not needed. With 50% probability modules
> will not be loaded, but who cares when cross-compiling?

underscores are only relevant for dynamic modules, the best solutions is
probably to default to the build system's facilities, because dynamic
modules require intensive system specific checks.

> 6) `e' -> `we'. Just an annoying mistyping.
> 7) Never use $host. Use $host_os instead, because this is more reliable.
> 8) Pessimistic value for getpwuid_r - assume that this function is not
> present or doesn't work.

as a base line, you can be pretty sure that your cross-compiled glib version
won't work on a system that has a different installation base than the
build system. if the installations do match however, you can simply run
./configure as usual (and use the build systems defaults with that) and later 
install on the target system.
to fix these annoying autoconf warnings ala
configure.in:256: warning: AC_TRY_RUN called without default to allow cross compiling
we are actually better off with placing AC_MSG_ERROR (cross compilation not
supported) as the fourth argument to any AC_TRY_RUN() invokations.


> 
> Pavel Roskin
> 

---
ciaoTJ