GNOME Bugzilla – Bug 79124
gtkmm should compile (and run) on Windows
Last modified: 2004-12-22 21:47:04 UTC
Sometime ago, it was mentioned on the gtkmm mailing list that it would be easier to port it to Windows when 2.0 arrived, since it's a goal for GTK+ 2.0 to run on Windows. This bug is to track the progress of porting gtkmm to Windows.
See this thread from the mailing list: http://marc.theaimsgroup.com/?t=101742099000003&r=1&w=2 We are just awaiting the patches from Cedric. I think he's on holiday or something at the moment, because we've been getting "mailbox full" errors from his email address.
The cvs version of gtkmm-1.3 compiles fine as a dll using mingw32 and the standard autotools. BUT, because I wanted to have full automatic DLL generation using libtool, it requires libtool 1.4e (and the corresponding autoconf 2.52 and automake 1.5b) as provided by cygwin as development (unstable) tools. Before I can send you the patches against the current cvs version, I have two questions/remarks : 1. gdk/dragcontext now implements a set_icon method that takes a Gtk::StockID as an argument. This can not work with DLLs because it creates a cross-dependence between the gdkmm and gtkmm libraries. Remember DLL are like executables, so no symbol should be undefined when libtool generates them. 2. A few methods are not yet implemented in the win32 port of gtk+- 2.0. I'd like to know what would be the best way to comment those methods out in the corresponding *.hg files. Right now, I simply added // in front of the _WRAP_METHOD macros but it means that these methods won't be accessible anymore from the unix port of gtkmm. Of course I tried to enclose them within a #ifndef _WIN32 .. #endif but these preprocessing macros get removed when the .h and .cc files are created. Any hint ? Apart from that the examples and the gtk-demo program work great !
1. Please change that to a Glib::ustring, with a non-windows-specifc commment next to it explaining why. I'm surprised that it works on linux either. It's a result of the nasty GDK/GTK+ organisation. 2. The preprocessing should not be removed from the .h file, but of course it will not appear in the .cc file. I've added a _GTKMMPROC_H_AND_C() macro, which can be used like so: _GTKMMPROC_H_AND_CC(#ifndef YADAYADA) _WRAP_METHOD(void set_label(const Glib::ustring& label), gtk_button_set_label) _GTKMMPROC_H_AND_CC(#endif) The #ifndef and #endif will then appear in both the .h and .cc file.
Ok, I'm almost ready to submit my patches. But before that, four questions : 1. Where should I submit my patches for libsigc++-1.1 ? 2. Should I add my win32 modifications to ChangeLog and/or write a README.win32 file ? 3. As stated before, the win32 port for mingw32 requires the latest release of autoconf and automake along with a CVS snapshot of libtool. This means that either we will have to provide two different source tarballs or require from the libsigc++ and gtkmm maintainer to use this latest autotools. Most probably, it's up to you, Murray ! Or maybe, you have another solution ? 4. Should I prepare a binary distribution (à la gtk+-2.0 for win32) ? Cedric
1. libsigc++ patches should go the the libsigc++ mailing list. Or you could add them to this bug and post a link to the mailing list. I can apply them. Make sure that you're subscribed to that list because it is only moderated every few months. 2. All changes should be mentioned in the Changelog. If you have separate build instructions then maybe they should go in a README.win32 or INSTALL.win32 file. 3. I'm using these tools: [root@localhost gnomemm]# libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) [root@localhost gnomemm]# autoconf --version autoconf (GNU Autoconf) 2.52 [root@localhost gnomemm]# automake --version automake (GNU automake) 1.4-p5 It should not be a problem to use the newer ones. Are you sure that the newer libtool will only be required on the autogen-ing computer? 4. If it's easier to provide a binary win32 distribution than it is to provide linux rpms then go ahead. But it shouldn't be necessary - the build from source should be straightforward.
I'd like to add that a README.win32 would be really excellent. I want my current application ported to Windows - so documentation for compiling gtkmm and its dependencies on Windows would be great. Then I can use time on porting code instead...
I haven't yet seen any libsigc++ patches on the mailing list.
Cedric, where are you?
I just came back tuesday from a 2 weeks vacation. I'm currently fighting with the latest autoconf/automake/libtool developement distribution provided by cygwin. It seems to be somewhat broken. I'm gonna try to revert back to an older snapshot. My patches to libsigc++ are basically ready. For gtkmm, there's only one last thing to do, which is adding my modifications to the ChangeLog. You can expect the final patches by monday.
Please give us those libsigc++ patches as soon as possible.
Created attachment 8958 [details] [review] Enable mingw32 support (dll creation)
Created attachment 8959 [details] Compilation notes for the mingw32 compiler and general win32 support
Ok, I just submitted to files : 1. The first one is a patch against the current (anonymous) cvs version of libsigc++ that adds support for the creation of a DLL on win32 using the mingw32 compiler. All the source modifications are explained in the ChangeLog. 2. The second file is a README.win32 file that should be added to the root direction of the libsigc++ distribution. It explains how to build the library on win32 using mingw32 and the autotools (autoconf/automake and libtool) If everything is Ok with these modifications to libsigc++, I will submit my patches to gtkmm tomorrow or the day after tomorrow, as soon as I have found the reason why gtkmm does not build anymore with the latest snapshot of gtk+ for win32. If required, I can also submit those patches to the libsigc project on sourceforge, although it seems the patch manager hasn't been enabled on this project Cedric
Thanks. I should be able to apply these next week, unless Daniel would like to do it for me instead.
Applied. I also replaced doc/win32 with Cedric's build notes, since the old content was outdated anyway.
I can confirm that the libsigc++ changes work, with cygwin on Windows 2000. I'd really like the gtkmm patches so that we can announce Win32 support in the next release. Are you working on MSVC++ build files too? I added an MSVC++ 7 project file to libsigc++ cvs, but there's a compiler error.
No, I haven't tried with MSVC++ compiler. My patches are ready but before I submit them, I'd like to fix one bug that appears only on win32 with the gtk-demo. The demo compiles and runs fine except for one thing : while openning the "Stock Item and Icon Browser" window, the icons in the "symbol" icon are not displayed and I get a bunch of warnings, telling me that "GLib-GObject-WARNING **: unable to set property `text' of type `gchararray' from value of type `GdkPixbuf'". I should point out that the stock icons are displayed as expected in the "selected item" box when I click on a table line. Any hint ? Could this be related to set_icon problem in gdk/dragcontext I mentioned earlier ? Cedric
Sounds like a fun bug. Could even be a compiler-related problem. Please submit your patches anyway, we can fix this bug later. Thanks, --Daniel
Ok, I'll leave this treeview bug like that. I'll write my modifications to the changeLog this weekend. You can expect my final patch on monday (Sorry no internet connection during the weekend).
Ok, I just created two attachments. As for libsigc++, the first one is a tentative README.win32, while the second is the patch to the current anonymous CVS version of gtkmm. I hope I didn't break anything for other platforms. I'll let you play with it over the weekend
Created attachment 9229 [details] [review] Gtkmm patch : Enable support for win32 (mingw)
Created attachment 9230 [details] Gtkmm : compilation notes for mingw and general win32 support
Cedric, I think we still need the config.h.in file. Actually, what is in there that can't go into glibmmconfig.h?
Created attachment 9268 [details] Gtkmm : config.h.in file
Sorry about the missing config.h.in file. I just sent an attachment. I contains a few #define macros on standard C functions that are not available on some platforms (including mingw32), namely flockfile, funlockfile and getc_unlocked. These are used in gtk-demo (demowindow.cc). You're right, those macros could be included into glibmmconfig.h.in. The reason why I didn't do it ? Mainly because I didn't want to polluate glibmmconfig.h, gdkmmconfig.h or gtkmmconfig.h with macros that are useless for and irrelevant to the gtkmm libraries once they have been compiled and installed. This also means that config.h doesn't need to be installed and that it can be used for the other test programs in the examples directory. To be more explicit, it might be useful to rename config.h.in. something like exampleconfig.h.in maybe ?
Can't we still allow gtkmm to build with automake 1.4-p5 also, as used by vicious-build-scripts? Can automake 1.5b be used to build the rest of GNOME2? I get this with automake 1.4p5: Building makefiles. gtk/src/Makefile.am:40: warning: automake does not support conditional definition of files_hg in EXTRA_DIST gtk/src/Makefile.am:25: warning: automake does not support conditional definition of files_hg in files_ccg gtk/gtkmm/Makefile.am:22: warning: automake does not support conditional definition of files_hg in files_built_cc As for config.h.in, I think I'll put it in the demos folder.
Conditional compiling with automake (the if PLATFORM_WIN32 ... endif test I added here and there) is a real mess, especially if you couple it with variable substitution, as in $(files_hg:.hg=.cc). I just realized this nasty bug was only fixed in automake-1.6 and up. I'm investigating other for handling this particular situation but I'm not an automake expert ! But I'd like to point out that proper creation of DLLs with mingw3é requires libtool-1.4.2 and up which requires autoconf 2.52 (which requires at least automake-1.6 if I remember correctly)
Re libtool: OK, but Unix users don't want to build Win32 dlls. I'd really prefer that this did not break existing Unix environments. Anything that prevents people from being involved is bad. I'd guess that Daniel has some advice about this conditional stuff.
Did you try to compile the library, even though automake is giving you those warnings ? I did on a linux box and it seems to be working fine (plug.cc and socket.cc are compiled as expected). Maybe pre-1.6 versions of automake are giving false warnings. My linux box (redhat 7.1 on a good old DEC alpha) uses libtool 1.3.5 automake 1.4 (I also got the automake warnings) autoconf 2.13 Turns out I encountered a somewhat unrelated problem : a syntax error when configure reaches the perl version test, where GTKMM_CV_PERL_VERSION is called ( [gtkmm_cv_perl_version_[]m4_translit (... ). I just commented out this section and the rest of the configure script went fine. This GTKMM_CV_PERL_VERSION macro is processed without any flaw by later versions of autoconf though !!! These autotools are starting to give me headaches.
Yes, but configure does not finish, probably because of those warnings. I, and GNOME2, are using these versions. We must support them. [root@localhost gtkmm-1.3]# automake --version automake (GNU automake) 1.4-p5 [root@localhost gtkmm-1.3]# autoconf --version autoconf (GNU Autoconf) 2.52 [root@localhost gtkmm-1.3]# libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)
Of course we also want to support gtkmm 1.2-era autotools versions if possible.
I applied the patch with some tweaks. (see ChangeLog for details, I'm too tired to elaborate right now :) I hope it works fine -- could you please try if it builds on Win32 now?
Thanks for the auto* fix, Daniel. It seems to work on win32 (with a few simple tweaks). In the meantime I came up with my own fix that excludes posix-related files from the build process, while including all generated files into the distribution and without relying on special gnu make features. The only thing that changes is the splitting of files_hg into files_general_hg, files_posix_hg and files_win32_hg (which could be nice if win32 related files are included into gtk+-2.0). This also means that we don't need your GTKMM_INSTALL_EXCLUDE and SECTION_CC_BEGIN and SECTION_CC_END macros. I'll send you my patch today and you'll be able to compare both solutions. I'm pretty sure we'll have a general and "elegant" building process really soon.
I have just attached the patch I described earlier. There are also two new files, to be copied into the build_shared directory. What remains to be done is to write some general purpose Makefile.am_fragment for the private directories. Could you try it and tell me what you think ? As I explained earlier, it doesn't use GTKMM_INSTALL_EXCLUDE (although it is still in configure.in) or m4 tricks.
Created attachment 9393 [details] [review] patch : Conditional build on win32 with automake 1.4-p5 and up
Created attachment 9394 [details] New build_shared\Makefile_build_extra.am_fragment file to be used with previous patch
Created attachment 9395 [details] New build_shared\Makefile_gensrc_platform.am_fragment file to be used with previous patch
Cedric, Glib::Dispatcher is supposed to work on Win32 (conditionally included API is evil). I just couldn't test and fix it yet. Maybe you've an idea how to make it work on Win32? BTW, we need a ChangeLog entry for your patch too. Thanks heaps for your effort. Cheers, --Daniel
But if you can't get it to work then do #ifdef it out and add a TODO.
On Win32, it's excluded from the build at the moment. If it isn't easy to port then just send us the ChangeLog so that we can apply what we have now, and worry about it later.
OK, I wrote the ChangeLog and committed the patch. It'll go into gtkmm-1.3.17. Cedric, could you confirm whether it works?
Everything is working fine now. About Glib::Dispatcher, I excluded it from the build process because it uses fcntl which is posix and has no direct equivalent on win32. I'm not a file descriptor/socket expert at all but I suppose it might be possible to find a workaround using winsock (if sombedo with win3é expertise wants to volunteer !). I guess we're facing the same exact problems as those encountered with giochannel.h where part of the API is currently not implemented on win32. Talking about win32 portability, multithreading is currently not supported for two reasons : 1. It is not supported by the native port of gtk+ on win32 (see README.win32 in the gtk+-2.0 source distribution). 2. C++ exceptions propagation across DLLs in mutithreaded applications does not work with the current distribution of mingw. this should be added to the README.win32 that I submitted as an attachment on June 14 (it hasn't been commited yet !). The thread and threadpool examples crash miserably when exiting.
README.win32 added to cvs and dist. Thanks both of you.