Re: Can glib-config or gtk-config support multiple compilation systems?

[Guido Draheim <guidod-2003- gmx de>]

Owen Taylor schrieb:
> > [...]
> > The glib and gtk+ libraries consist of C source code and the ABI is
> > the same for all compilers.  One set of runtime would work for all
> > compilers, but the xxx-config scripts would not.  A single xxx-config
> > script would only return the flags that work with the C compiler used
> > to build glib or gtk+, not the compiler being used to build products
> > X, Y or Z.
>
>  
> Frequently the GLib header files are _not_ the same for different 
> compilers. GLib does various compiler specific checks and puts
> the output into /usr/lib/glib/glibconfig.h.
>
> For that reason, the prototypical setup is that you have one
> copy of GLib per compiler.
>
>
> > Typically the configure scripts for product X would set the appropriate
> > CCFLAGS or LDFLAGS based on the compiler being used - CC=/usr/gnu/bin/gcc
> > or CC=/usr/ccs/bin/cc.  Given, the configure.in may need to be tweaked
> > and while that is not ideal, it is better than getting the incorrect set
> > of flags as reported by a single compiler unaware glib-config script.
> >
> > Have you given this problem any consideration? 
> >
> > Is there a way to support multiple compilers with one instance of the Gimp 
> > development toolkit that I have not seen?
>
>
> Not out of the box. You could compile a couple of copies of GLib, then 
> edit the glib-config files so that they share everything but 
> glibconfig.h. 
>
> Then, compile GTK+ with one compiler and manually 
>
> Then put the glib-config and gtk-config files into separate paths
> per compiler:
>
>  /opt/gtk/gcc-bin/{glib,gtk}-config
>  /opt/gtk/cc-bin/{glib,gtk}-config
>
> Or something. Then people would only need to set the path based
> on the version of glib/gtk being used. 
>
> Or you could even get fancy and make glib/gtk-config automatically
> switch glibconfig.h and C compiler flags based on the setting
> of $CC, but that strikes me as unreliable ... I think, for instance,
> that autoconf will always use gcc when found unless $CC is 
> explicitely set.
>
> So, basically, no it's not something that we handle upstream,
> but it shouldn't be hard to craft an appropriate solution.

Perhaps it can be done simpler - choose different include-areas
for the two compilers but the same install-area for the
libraries - that can be done with the help of `configure`
options --libdir and --includedir. Since in this case the two
`config`s are needed too, it might be interesting to use just
two different --prefix's for the two compiler staging areas
and combined with the same --libdir path.

configure --prefix=/usr/gcc   --libdir=/usr/lib # for gcc
configure --prefix=/opt/xcc   --libdir=/usr/lib # for *cc

That will result in two configs in the /usr/gcc/bin and
/opt/xcc/bin but just one instance of the shared library.
Later applications that link with the library will use
only one instance, and consequently no bloat for the runtime
environment as applications will only load one instance
of a sharedlib glib/gtk to memory.

Using `configure` options does not require to post-edit
any of the scripts IMO. Just the later compile environments
need to be adapted to find the correct *-config - which
can be achieved with modifying $PATH. Warning: my real
world experience shows that there are problems when there
are other library dependencies (non-gtk/glib) that make
for more -Includes that will make the compiler find the
include-headers made up for just the other compiler. The
two should be kept separate and that's not easy to do
globally. Using $PATH and -Include modifications is
always a bit dangerous but OTOH the easiest to get away
with configure`d install-headers and compile-helpers.

cheers, guido          http://ac-archive.sf.net/largefile