Re: Smoother cross compilation of 1.3.12

[Michael Taht <mtaht mvista com>]

Correction to previous mail - "CROSS_COMPILE_PREFIX" throughout, no
CROSS_COMPILE_DIR.

On Tue, 2002-01-08 at 16:13, Michael Taht wrote:
> I've managed to cross compile the related libraries for gtk 1.3.12 for a
> variety of architectures. It's painful, but doable.
> 
> A couple comments on making this easier, but first some background on
> what I'm doing and how. The linux environment I'm working in supports
> cross compilation, from a host of x86/ppc/solaris to a target of
> mips/arm/x86/ppc. It also supports native compilation on the
> mips/arm/x86/ppc box.
> 
> The target machine usually NFS mounts its root directory from /opt/*. I
> note (usually). So the cross compilation process has to be able to
> dynamically place the libraries and binaries anywhere on the filesystem
> - and yet support native compilation, and preferably do all of it from
> the databases kept on the target systems /opt/*/usr/lib/pkgconfig and
> /opt/*/usr/lib/*.la (dirs, and others)
> 
> Therein lies problems A & B. 
> 
> pkg-config has no real notion of cross compilation except for the
> bootstrapping process {pc_top_builddir}. 
> 
> The .pc files for the related packages, although they have the ability
> to overwrite the --prefix, --libdir, etc, tend not to use the prefixes
> in actual use for the libdir arg. (see pango-0.23 for an example -
> libdir and includedir do not depend on {prefix})
> 
> There's three ways to do it - one is keep a separate pkgconfig database
> on the host machine, and hand tweak the .pc files if the target dir
> moves. A second is to normalize the .pc files, run a script to extract
> out the prefix info on a per file basis, and do other magic to insure
> that the libdir is actually wherever it is at compile time.
> 
> and the third way is to patch pkgconfig to use a new environment
> variable and ask (beg), pkg-config users to use it or something like it
> in creating their .pc files. 
> 
> I chose the third way.
> 
> Patched pkgconfig to support an environment variable
> "CROSS_COMPILE_DIR", and modified the 
> 
> Now I can have one database of pkgconfig code, modifiable at
> compiletime... if only I can convince the world to stick a:
> 
> prefix=${CROSS_COMPILE_PREFIX} prefix@
> 
> in their pc files.
> 
> patches available on request. Also patched pkg-config to use the native
> glib library rather than build it's own as compiling glib is a pain...
> as per problem C)
> 
> Problem B) autoconf
> 
> All the new code and much of the higher end code (gnome, etc) depend on
> libtool. My personal feelings about this obscure shell script aside,
> it's got problems in a cross compilation environment - typically libtool
> will fail on a link step because it decodes a .la file, then does magic
> parsing of a -lsomething into a /usr/lib/something.so - which is
> typically a native host library and not what I want.
> 
> It would be really great to just turn off -l parsing in libtool and let
> the gcc compiler figure it out. I couldn't figure it out. 
> 
> so I wrote a script that postprocesses and demangles the libtool
> generated .la file. 
> 
> It gets rid of /usr/lib/*.la references, the -L references, any
> hardcoded paths to -l in the dependency_libs variable, and makes
> libdir=$CROSS_COMPILE_PREFIX'/usr/lib', etc.
> 
> Is there a better solution?
> 
> Problem C) glib-1.3.12 requires a plethora of environment variables in
> order to get through configure, and a couple patches to configure.in,
> and 
> 
> (this is where the ability to do a native compile, at least once, is
> really handy)
> 
> For the record, for hard hat linux, these were:
> 
> export ac_cv_func_getpgrp_void='yes'
> export ac_cv_func_setvbuf_reversed='no'
> export ac_cv_sys_restartable_syscalls='yes'
> export ac_cv_func_getpwuid_r='yes'
> export ac_cv_func_posix_getpwuid_r='yes'
> export glib_cv_has__inline='yes'
> export glib_cv_has__inline__='yes'
> export glib_cv_hasinline='yes'
> export glib_cv_sane_realloc='yes'
> export glib_cv___va_copy='yes'
> export glib_cv_va_copy='no'
> export glib_cv_va_val_copy='yes'
> export glib_cv_sizeof_gmutex=24
> export glib_cv_rtldglobal_broken='no'
> export glib_cv_uscore='no'
> export glib_cv_stack_grows=no
> export ac_cv_sizeof_pthread_mutex_t=24
> export ac_cv_sizeof_fpos_t=12
> export ac_cv_sizeof_float=4
> export ac_cv_sizeof_char=1
> export ac_cv_sizeof_void_p=4
> export ac_cv_sizeof_int=4
> export ac_cv_sizeof_long_long=8
> export ac_cv_sizeof_off_t=4
> export ac_cv_sizeof_pthread_t=4
> export glib_sizeof_pthread_t=4
> export ac_cv_sizeof_short=2
> export ac_cv_sizeof_double=8
> #export ac_cv_page_size=4096 ? 
> export ac_cv_sizeof_wchar_t=4
> export ac_cv_sizeof_uintptr_t=4
> export ac_cv_sizeof_long=4
> export glib_cv_sizeof_size_t=4
> export glib_cv_sizeof_ptrdiff_t=4
> export glib_cv_sizeof_intmax_t=4
> export glib_cv_sizeof_system_thread=4
> export ac_cv_sizeof___int64=8
> export glib_cv_long_long_format=ll
> export posix_priority_min='sched_get_priority_min(SCHED_OTHER)'
> export posix_priority_max='sched_get_priority_max(SCHED_OTHER)'
> 
> 
> export glib_genmarshal=%{_hhl_host_bin_dir}/glib-genmarshal
> 
> Note that glib_genmarshal thing - yes, you need to natively compile
> glib2 before you can cross compile it. It would be nice to have
> CROSS_COMPILE support in the makefiles for host and target, but, all
> I did was patch the makefile to allow genmarshal to be a external
> program so you do a make glib-genmarshal=local_glib_genmarshal
> 
> 
> --- gobject/Makefile.am Sat Nov 17 16:38:47 2001
> +++ gobject/Makefile.am.new     Thu Dec 27 00:35:34 2001
> @@ -157,13 +157,13 @@
>  $(srcdir)/stamp-gmarshal.h: @REBUILD@ gmarshal.list gmarshal.h
> glib-genmarshal$(EXEEXT)
>         echo "#ifndef __G_MARSHAL_H__" > xgen-gmh \
>         && echo "#define __G_MARSHAL_H__" >> xgen-gmh \
> -       && ./glib-genmarshal --nostdinc --prefix=g_cclosure_marshal
> $(srcdir)/gmarshal.list --header >> xgen-gmh \
> +       && $(glib_genmarshal) --nostdinc --prefix=g_cclosure_marshal
> $(srcdir)/gmarshal.list --header >> xgen-gmh \
>         && echo "#endif /* __G_MARSHAL_H__ */" >> xgen-gmh \
>         && (cmp -s xgen-gmh $(srcdir)/gmarshal.h || cp xgen-gmh
> $(srcdir)/gmarshal.h) \
>         && rm -f xgen-gmh xgen-gmh~ \
>         && echo timestamp > $@
>  $(srcdir)/gmarshal.c: @REBUILD@ $(srcdir)/stamp-gmarshal.h
> -       ./glib-genmarshal --nostdinc --prefix=g_cclosure_marshal
> $(srcdir)/gmarshal.list --body >> xgen-gmc \
> +       $(glib_genmarshal) --nostdinc --prefix=g_cclosure_marshal
> $(srcdir)/gmarshal.list --body >> xgen-gmc \
>         && cp xgen-gmc $(srcdir)/gmarshal.c \
>         && rm -f xgen-gmc xgen-gmc~
>  $(srcdir)/gmarshal.strings: @REBUILD@ $(srcdir)/gmarshal.list
> 
> 
> And so on.
> 
> Another patch to configure.in
> 
> --- configure.in        Thu May  3 18:32:12 2001
> +++ configure.in.new    Thu May  3 18:34:05 2001
> @@ -1022,6 +1022,9 @@
>                         G_THREAD_LIBS="-pthread"
>                 fi
>                 ;;
> +            *linux*) # Linux has pthreads. Period. Why test?
> +                       G_THREAD_LIBS="-lpthread"
> +               ;;
>               *)
>                 for thread_lib in "" pthread pthread32 pthreads c_r
> thread dce; do
>                         if test x"$thread_lib" = x; then
> 
> 
> 
> A more controversial patch to configure.in - I don't need ansi
> prototypes - but I suppose we should propose environment variables that
> would let you bypass this test. 
> 
> --- configure.in        Thu Nov 22 10:00:09 2001
> +++ configure.in.new    Wed Dec 26 23:39:58 2001
> @@ -312,26 +312,6 @@
>    fi
>  fi
> 
> -dnl DU4 native cc currently needs -std1 for ANSI mode (instead of K&R)
> -AC_MSG_CHECKING([for extra flags to get ANSI library prototypes])
> -glib_save_LIBS=$LIBS
> -LIBS="$LIBS -lm"
> -AC_TRY_RUN([#include <math.h>
> -             int main (void) { return (log(1) != log(1.)); }],
> -     AC_MSG_RESULT(none needed),
> -     glib_save_CFLAGS=$CFLAGS
> -     CFLAGS="$CFLAGS -std1"
> -     AC_TRY_RUN([#include <math.h>
> -                 int main (void) { return (log(1) != log(1.)); }],
> -         AC_MSG_RESULT(-std1),
> -         AC_MSG_RESULT()
> -         CFLAGS=$glib_save_CFLAGS
> -         AC_MSG_WARN(
> -                [No ANSI prototypes found in library. (-std1 didn't
> work.)])
> -     )
> -)
> -LIBS=$glib_save_LIBS
> -
>  dnl NeXTStep cc seems to need this
>  AC_MSG_CHECKING([for extra flags for POSIX compliance])
>  AC_TRY_COMPILE([#include <dirent.h>], [DIR *dir;],
> @@ -1424,7 +1404,10 @@
>                         [AC_MSG_RESULT(yes)
>                           AC_DEFINE(G_THREAD_USE_PID_SURROGATE, 1,
> [whether to use the PID niceness surrogate for thread priorities])
>                          ],
> -                       [AC_MSG_RESULT(no)])
> +                       [AC_MSG_RESULT(no)],
> +                       [AC_MSG_RESULT(yes)
> +                         AC_DEFINE(G_THREAD_USE_PID_SURROGATE, 1,
> [whether to use the PID niceness surrogate for thread priorities])
> +                        ])
>         elif test x"$have_threads" = xwin32; then
>                 # It's a pointer to a private struct
>                 GLIB_SIZEOF(,struct _GThreadData *, system_thread)
> 
> 
> And this patch is just me being lazy. I suspect some cpp hacking might
> "just work".
> 
> --- acglib.m4   Fri Dec  8 14:48:45 2000
> +++ acglib.m4.new       Thu May  3 16:59:57 2001
> @@ -111,6 +111,7 @@
>  else
>    glib_nl='\n'
>  fi
> +if false; then
>  AC_MSG_CHECKING(system definitions for $glib_sysdef_msg)
>  cat >confrun.c <<_______EOF
>  #include <stdio.h>
> @@ -146,4 +147,10 @@
>         done
>         AC_MSG_RESULT(failed)])
>  rm -f confrun.c
> +else
> +echo -e "#define GLIB_SYSDEF_POLLIN =1\n#define GLIB_SYSDEF_POLLOUT =4
> +#define GLIB_SYSDEF_POLLPRI =2\n#define GLIB_SYSDEF_POLLERR =8
> +#define GLIB_SYSDEF_POLLHUP =16\n #define GLIB_SYSDEF_POLLNVAL =32"
> >>$glib_sysdefso
> +AC_MSG_RESULT(done)
> +fi
>  ])
> 
> Problem D) pango
> 
> pango wants to run tools and tests even if cross compiling. Should just
> default to generating them. Trivial patch...
> 
> Problem E) gtk+ 
> 
> At this point gtk+ cross compiles... with a few more trivial patches
> along the same lines as the above.....
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list