GNOME Bugzilla – Bug 137591
Build failure when building in a Cygwin/win32 environment
Last modified: 2005-01-25 09:32:51 UTC
Attached is a patch to allow Gtkmm to built in a Cygwin environment. The patch isn't intended to be applied "as-is", since some things are broken. On the whole, the source assumes that: - A UNIX environment is using the X11 backend - Win32 means MinGW - but Cygwin behaves like a UNIX environment, while requiring -no-undefined as a linker option, and may optionally use the win32 GDK backend rather than X11. This patch (hopefully) corrects a few of these assumptions. gtkmm-2.2.9.old/build_shared/Makefile_build.am_fragment: Essential to build DLLs with Cygwin. Will not break MinGW. gtkmm-2.2.9.old/gtk/gtkmm/plug.cc } None of these should be gtkmm-2.2.9.old/gtk/gtkmm/plug.h } applied. The build is gtkmm-2.2.9.old/gtk/gtkmm/socket.cc } buggy when using a gtkmm-2.2.9.old/gtk/gtkmm/socket.h } win32 GDK backend, since gtkmm-2.2.9.old/gtk/src/plug.ccg } Gtk::Plug and Gtk::Socket gtkmm-2.2.9.old/gtk/src/plug.hg } don't exist, but they are gtkmm-2.2.9.old/gtk/src/socket.ccg } built and linked anyway gtkmm-2.2.9.old/gtk/src/socket.hg } (linking fails, naturally). I don't have a fix for this, but Gtk::Plug and Gtk::Socket should only be built if GDK_WINDOWING_X11 is defined, and not if GDK_WINDOWING_WIN32 is defined. The assumption that a UNIX environment == X11 needs to be removed. I'm not familiar enough with the intricacies of your build system to do this, unfortunately. I've thought of two solutions here: 1) Write a configure check to check whether libgdk defined GDK_WINDOWING_WIN32 or GDK_WINDOWING_X11, and then conditionally compile plug.cc and socket.cc 2) Build plug.cc and socket.cc, but surround all the methods etc. with #if defined(GDK_WINDOWING_X11) or #if !defined(GDK_WINDOWING_WIN32) (I'm not sure what's most appropriate, or how this will fit in with gmmproc). gtkmm-2.2.9.old/gtk/gtkmm/wrap_init.cc } gtkmm-2.2.9.old/tools/extra_defs_gen/generate_defs_gtk.cc } gtkmm-2.2.9.old/tools/generate_wrap_init.pl.in } Essential to build with a GDK win32 backend on Cygwin. Will not break MinGW. After applying this patch, the build proceeds properly, and I get a working set of Cygwin DLLS (cygatkmm, cygpangomm, cygglibmm and cyggtkmm etc.). The tests and demos all work just fine, with a single exception: in gtk-demo, the "Images" demo fails with Failed to load image: Unrecognized image file format and the images are replaced with the "no image" icon. In addition, the "Pixbufs" and "Text Widget" demo also fail: $ ./demo Aborted (core dumped) I've tried running in a debugger (gdb) run Starting program: /cygdrive/c/tmp/build/gtkmm-2.2.9/demos/gtk-demo/.libs/demo.exe 5 [sig] demo 2424 open_stackdumpfile: Dumping stack trace to demo.exe.stackdump Program exited with code 0303000. but there's no stack to examine. I'm sure the problem is with gdk-pixbuf, but I'm unsure where (gtk-demo works flawlessly). I've built against GTK+ 2.2.4. The "demo.exe.stackdump" looks like this: Stack trace: Frame Function Args 0022DF08 77E7AC21 (00000000, 00000008, 0022DF38, 610A0108) 0022DF68 61087E49 (00000978, 00000006, 0022DF98, 610883B3) 0022DF78 61087EFC (00000006, 00000000, 77E75A65, 610A008D) 0022DF98 610883B3 (0022DFB0, DF0DF047, 00000000, 6109E8BE) 0022DFE8 61086211 (00A99930, 0022E144, 0022E018, 0076174E) 0022DFF8 00763425 (10231C60, 0022E040, 77E75A65, 10294068) 0022E018 0076174E (0022E040, DF0DF047, 00000000, 6109E8BE) 0022E078 0074CEA4 (00796030, DF0DF046, 0022E098, 6109B72B) 0022E118 0074D2FF (102A6338, 0022E140, 1028A3A8, 01A7CFA0) 0022E198 01A50D64 (1025E8F0, 102943B8, 102856F8, 1028A1F0) 0022E1C8 0131E2D3 (1028A3D8, 00000000, 00000003, 0022E3C0) 0022E218 00DB39DD (1028A3D8, 00000000, 00000003, 0022E3C0) 0022E2F8 00DC7BB8 (102587A8, 00000000, 1025E8F0, 00000000) 0022E558 00DC6E18 (1025E8F0, 00000052, 00000000, 0022E594) 0022E578 00DC7026 (1025E8F0, 00000052, 00000000, 102946A0) 0022E5A8 013F7446 (1025E8F0, 102946A0, 102856F8, 0022E604) End of stack trace (more stack frames may be present) but this doesn't look too informative... Any suggestions about how to debug this further would be greatly appreciated! Many thanks, Roger
Created attachment 25765 [details] Cygwin build patch 1
WRT the crashes when trying to load images: this was because /etc/gtk-2.0/gdk-pixbuf.loaders was empty. Generating this with gdk-pixbuf-query-loaders did the trick. I can now load images in plain C GTK+ programs. The Gtkmm gtk-demo/demo "Image" demo now works, but the "Pixbufs" demo still causes a crash. There's a slight pause before the crash, so it might be a memory leak.
I can not read that attachment. What is the filename?
The attachment is a bzip2ed patch i.e. patch.bz2
I propose to target gtkmm-2.4 instead of gtkmm-2.2 for this building problem on win32, as the autotools magic is cleaner in the 2.4 branch since my last win32 patch. In particular, plug and socket are already compiled conditionaly for mingw32, so it should not be a big problem to have this done properly with cygwin. I'm currently building gtk+- 2.4 with the win32 backend on cygwin. Before going deeper into gtkmm/cygwin, I want to make sure that gtk+ indeed works as expected with cygwin.
Roger, I saw your post (http://mail.gnome.org/archives/gtk-list/2004- March/msg00162.html) on the gtk-list mailinglist. Did you find some time to port tour patches to the 2.4 branches of glib/atk/pango/gtk+ ? Could you sent them to me ? Once again, I think it will be easier to have a working port of gtkmm for cygwin if we focus on both gtkmm and gtk+ CVS.
I haven't had a chance to build any GTK+ 2.4 packages yet. In particular, I have not yet got GLib 2.3 to build (it builds, but the testsuite fails in a few places). I will check out the current GTK+/GLib CVS (or is 2.4.x on a branch?). I'll see what I can do this weekend.
I've fixed a bunch of issues with the current glib CVS. Everything now builds and works except for tests/child-test.c, which hangs forever. I've attached the patches for your perusal (each has been filed separately as a bug against glib/win32. Regards, Roger
Created attachment 26070 [details] rl-glib-CVSHEAD-cygwin-patches.tar This is a tarfile containing bzip2ed patches.
What is the glib patch number? Please make this bug dependent on it.
I think they are now mostly applied. I'll check the current CVS.
What is the status of this now?
The glib patches are now in glib 2.4.1+. I haven't yet had a chance to get the current stable atk/pango/gtk to build, but the cygnome2 folks at sourceforge are working on it. It's certainly not ready to build glibmm/gtkmm etc. yet. Regards, Roger
Could you take another look at this, please?
GTK+ 2.4.x and all its dependencies are now available directly in Cygwin. I'll try building GTKmm 2.4.x when I get a chance. Regards, Roger
Any progress, Roger?
Not yet. Unfortunately, the project at work I was using Cygwin and Gtkmm for stalled some months ago, and so I haven't had any need for GTK+ or Gtkmm on Cygwin myself. While I will certainly try to look at it, my Debian and Linux commitments are currently taking a higher priority. I have a week off work over Christmas, so I'll try to take a look then. I'll build against the official Cygwin GTK+ packages, so I'll have to build Gtkmm 2.4.x rather than 2.5/2.6. Is that OK? Regards, Roger
> so I'll have to build Gtkmm 2.4.x rather than 2.5/2.6. Is that OK? That's probably a good idea to keep things simple. If you don't take this further then please write a short summary of the status of this bug, so that it can be continued later.
Cygwin 20050104, using GTK+ 2.4.x with the X11 backend: libsigc++-2.0.6: ./configure -C --prefix=/usr --enable-shared --disable-static - configure OK - build OK - check OK - install into DESTDIR OK - install OK glibmm-2.4.5: ./configure -C --prefix=/usr --enable-shared --disable-static - configure OK - build OK - check OK (examples and tests) - install into DESTDIR OK - install OK gtkmm-2.4.8: ./configure -C --prefix=/usr --enable-shared --disable-static - configure OK - build OK - check OK, but gtk-demo/demo.exe segfaults on the "Pixbufs" demo (The C demo is fine). gdb wouldn't work (segfaulted in gtk_init); a Cygwin problem AFAICT. I had this problem with Gtkmm 2.2. - install into DESTDIR OK - install OK So I think it's probably OK. I'm now building GTK+ 2.6, but this is going to take a while longer (building and installing Gtkmm alone took 20 hours). I should have it all built in a few weeks (I'll build using the win32 backend, since that was what the original bug was about, but the C libraries will likely have new portability bugs which will need fixing first (2.2 and 2.4 did, and I've already found three in GLib 2.6.0). I'll let you know how I get on with Gtkmm/Glibmm 2.5/2.6 Regards, Roger
Many thanks. Please file a separate bug about the pixbuf demo segfault.
Closing, because everything (apart from the demoo segfault) seems to have been dealt with.