[EMAIL PROTECTED] (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 _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list