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

[Owen Taylor <otaylor redhat com>]

jlw caldera com (John Wolfe) writes:

> I am beginning a port/build of the Mozilla 1.2.1 release for 
> UnixWare 7.1.3 and of course need to build glib and gtk+
> in order to build mozilla.
> 
> I have no problems building all 3 products with a single 
> set of compilation tools.  I can restrict the released material
> to include just the glib and gtk+ runtime libraries that are
> needed by mozilla.
> 
> Ideally, I would like to release the gtk+ as a "supported"
> development tool on UnixWare 7.1.x, but I foresee a major
> stumbling block with glib-config and gtk-config on a system
> where there may be 3 separate compilation systems - each with
> different compilation/link flags

[ 
  Note that the GTK+ team no longer really supports GTK+-1.2
  at this point. Though after 4 years of deployment, it doesn't
  need all that much support any more.
]
 
> On UnixWare, we have 2 supported compilers:
> 
>                         ccflags                   ldflags
> 
>    "native" cc        -Kthread                    -Kthread
>                       -Kpthread                   -Kpthread
> 
>    "supported" gcc    -pthread                    -pthread
>       2.95.3  
> 
>   where -Kthread and -pthread are effectively a -D_REENTRANT on compilations
>   and a -l<thread> at the correct position on link command.
> 
> and numerous unsupported compilers such as user built gcc releases
> where:
> 
>    ccflags = -D_REENTRANT
>    ldflags = -lpthread
>    
> 
> 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.

Regards,
                                        Owen