After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 137591 - Build failure when building in a Cygwin/win32 environment
Build failure when building in a Cygwin/win32 environment
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: build
2.4
Other Windows
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on: 138402 138403 138404 138405 138412 138423 138425
Blocks:
 
 
Reported: 2004-03-18 14:07 UTC by Roger Leigh
Modified: 2005-01-25 09:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Cygwin build patch 1 (2.30 KB, application/octet-stream)
2004-03-18 14:08 UTC, Roger Leigh
Details
rl-glib-CVSHEAD-cygwin-patches.tar (20.00 KB, application/octet-stream)
2004-03-29 16:16 UTC, Roger Leigh
Details

Description Roger Leigh 2004-03-18 14:07:05 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
Comment 1 Roger Leigh 2004-03-18 14:08:02 UTC
Created attachment 25765 [details]
Cygwin build patch 1
Comment 2 Roger Leigh 2004-03-18 16:14:28 UTC
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.
Comment 3 Murray Cumming 2004-03-20 19:35:49 UTC
I can not read that attachment. What is the filename?
Comment 4 Roger Leigh 2004-03-20 23:38:13 UTC
The attachment is a bzip2ed patch i.e. patch.bz2
Comment 5 Cedric Gustin 2004-03-21 20:43:49 UTC
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. 
Comment 6 Cedric Gustin 2004-03-25 14:55:06 UTC
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. 
Comment 7 Roger Leigh 2004-03-26 15:08:13 UTC
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.
Comment 8 Roger Leigh 2004-03-29 16:15:44 UTC
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
Comment 9 Roger Leigh 2004-03-29 16:16:45 UTC
Created attachment 26070 [details]
rl-glib-CVSHEAD-cygwin-patches.tar

This is a tarfile containing bzip2ed patches.
Comment 10 Murray Cumming 2004-04-29 15:39:44 UTC
What is the glib patch number? Please make this bug dependent on it.
Comment 11 Roger Leigh 2004-04-29 21:54:15 UTC
I think they are now mostly applied.  I'll check the current CVS.
Comment 12 Murray Cumming 2004-07-08 16:30:24 UTC
What is the status of this now?
Comment 13 Roger Leigh 2004-07-09 08:36:30 UTC
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
Comment 14 Murray Cumming 2004-10-07 14:07:04 UTC
Could you take another look at this, please?
Comment 15 Roger Leigh 2004-10-16 15:31:18 UTC
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
Comment 16 Murray Cumming 2004-12-16 19:33:47 UTC
Any progress, Roger?
Comment 17 Roger Leigh 2004-12-16 20:51:33 UTC
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
Comment 18 Murray Cumming 2004-12-17 08:33:20 UTC
> 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.
Comment 19 Roger Leigh 2005-01-07 12:41:01 UTC
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
Comment 20 Murray Cumming 2005-01-08 07:54:19 UTC
Many thanks. Please file a separate bug about the pixbuf demo segfault.
Comment 21 Murray Cumming 2005-01-25 09:32:51 UTC
Closing, because everything (apart from the demoo segfault) seems to have been
dealt with.