GNOME Bugzilla – Bug 98312
Build problem under MinGW 2.0 / Cygwin
Last modified: 2004-12-22 21:47:04 UTC
gtkmm-2.0.0 compilation fails under MinGW 2.0 / Cygwin environment.
Created attachment 12253 [details] [review] gtkmm2-win32-mingw-2.0.patch
This patch adds 1) -mms-bitfields g++ option for MinGW gcc3. This option is needed to compile GTK programs under Win32 platforms. 2) --export-all-symbols ld option for MinGW ld. This option is needed to build DLL using the latest CVS head of libtool.
Created attachment 12254 [details] [review] gtkmm2-win32-macro.patch
This patch solves Win32-specific macro problem. 1) Glib::ThreadPriority enum in glib/glibmm/thread.h THREAD_PRIORITY_NORMAL is previously defined as macro in winbase.h 2) Gdk::EventType enum in gdk/gdkmm/event.h DELETE is previously defined as macro in winnt.h 3) Gdk::Status enum in gdk/gdkmm/types.h ERROR is previously defined as macro in wingdi.h 4) Gdk::Stock::DELETE in gtk/gtkmm/stock.{h,cc} DELETE is previously defined as macro in winnt.h
Cedric, could you please try these patches? Personally I use the following versions of GNU autotools. autoconf 2.52 automake 1.6.3 libtool 1.4e (latest CVS head) And I run configure under Cygwin environment like this $ cp config.site c:/gtkmm/etc $ env CXX='g++ -march=pentium' \ LDFLAGS='-Lc:/gtkmm/lib' \ AR=/usr/bin/ar \ ./configure \ --prefix=c:/gtkmm \ --disable-static \ --build=i386-pc-mingw32 config.site is needed for the latest CVS libtool. Attached config.site settings are ripped from MinGW/etc/config.site. This might be unnecessary in the future libtool-1.5 release.
Created attachment 12255 [details] config.site
Re gtkmm2-win32-mingw-2.0.patch: - Is this the first time that someone tried using gcc 3.x on win32. Didnt' we have this bitfields thing already? Why does it build for Cedric Gustin already? - libtool: Why do we care about a cvs version of libtool? Re. gtkmm2-win32-macro.patch: - Some of those are generated files, so patching will have no effect. Try producing cvs patches to avoid this.
Re gtkmm2-win32-mingw-2.0.patch: - I suggested that Cedric should submit a patch for gcc3, but I couldn't find his work in CVS source. So I submitted this patch. - latest libtool has some advantages over 1.4.x, especially in Win32 DLL. Cygwin and MinGW people are working toward a new auto-import-based DLL building. impgen is no longer needed, and binutils ld is used to build DLL. Cygwin is shipped with libtool-1.4e. Anyway, when we are using libtool-1.4.2, --export-all-symbols ld option doesn't not affect the DLL building, and there is no problem.
Murray, if you don't want to apply --export-all-symbols ld option patch, please use the following ms-bitfields only patch.
Created attachment 12286 [details] [review] gtkmm2-win32-ms-bitfields.patch
Re. gtkmm2-win32-macro.patch: Are gtk/gtkmm/stock.{h,cc} generated files? I produced these patches against the CVS source using cvs diff command.
> Re. gtkmm2-win32-macro.patch: > Are gtk/gtkmm/stock.{h,cc} generated files? I produced these patches > against the CVS source using cvs diff command. Sorry. Ignore that. I would hope that gtkmm2 could be built on win32 without rerunning autoconf/automake/libtoolize. So I would hope that the libtool files in the tarball are enough. If this is not possible then I hope it's documented in README.win32. I'm sorry to delay this, but I will need Cedric Gustin to approve the changes.
> I would hope that gtkmm2 could be built on win32 without > rerunning autoconf/automake/libtoolize. So I would hope > that the libtool files in the tarball are enough. It is not so difficult. What release maintainers should do is only use autoconf-2.52 and fixed version of libtool-1.4.[23]. autoconf-2.52 - LIBTOOL_USE_WIN32_DLL macro of libtool-1.4.x has AC_PROVIDE problem with autoconf >= 2.53. libtool-1.4.[23] - impgen.c in libtool.m4 has a bug described on Bug 91033 bugzilla page. Unfortunately, libtool people have no intention to improve 1.4 series any longer (It is the reason why my first MinGW 2.0 patch includes libtool-cvs support). So we have to fix impgen.c bug by ourselves. The following libtool patches fix it.
Created attachment 12299 [details] [review] libtool-1.4.2-impgen-bug.patch
Created attachment 12300 [details] [review] libtool-1.4.3-impgen-bug.patch
> autoconf-2.52 - LIBTOOL_USE_WIN32_DLL macro of Sorry, this is typo. AC_LIBTOOL_WIN32_DLL
I tested the gtkmm2-win32-macro.patch and gtkmm2-win32-ms- bitfields.patch patches. They both work fine and should be appied to CVS. Thanks again Naofumi ! About the autotools/libtool problem, I think the best is to explicitly state in the README.win32 that autoconf-2.52 and (a modified) libtool-1.4.2 are required (that's what I use), and to provide a win32 targeted source distribution (.tar.gz) that compiles out of the box (with the right wrap_init.cc !!!). Binaries would be fine too (The windows world is a world of binaries, not sources).
What's the problem with wrap_init.cc. I thought we fixed some problem with this? Why would users need both autotools _and_ their own tarball? autotools should not be required to run configure.in.
Naofumi, if they don't want to fix libtool 1.4.x (and I'd like to see some message saying why they won't apply a simple patch) then is there a stable 1.5 on the way that we will be able to use instead? We are already using autoconf 2.5.2, but we should prepare to use future versions too.
gtkmm2-win32-macro.patch and gtkmm2-win32-ms-bitfields.patch applied.
wrap_init.cc is included in the source tarball and, because it is generated on a unix platform, it contains references to (gtk) socket and plug. Both types are not supported on win32. When working on win32 with the cvs version and with the --enable- maintainer-mode in the configure script, wrap_init.cc is generated, as expected, without any reference to plug and socket. So, we have three solutions here : 1. Fix the perl script that generates wrap_init.cc to make sure that no reference to socket and plug is included when building on win32. 2. Ask people to use --enable-maintainer-mode in configure and delete wrap_init.cc if they build gtkmm on win32 from the official source tarball. 3. Provide a win32-specific source tarball for each gtkmm release. Solution 1 is of course the best one but I'm not a perl specialist... Solution 2 is probably the worst Solution 3 might be the most appropriate one, taking into account the libtool problems we encounter on win32. The libtool patch provided by Naofumi, which solves the impgen bug, is against libtool.m4, which means that people building on win32 will have to : 1. Apply the patch 2. Run aclocal, then automake, then autoconf before starting the configure script. The autotools will be required, except if we provide win32-specific tarballs. There's currently no other way !
wrap_init.cc uses GTKMM_WIN32 #ifdefs. Why isn't this working?
I agree with Murray. wrap_init.cc has no problem. What win32 users require is only the source tarball maintained by using fixed libtool 1.4.
> Naofumi, if they don't want to fix libtool 1.4.x (and I'd > like to see some message saying why they won't apply a > simple patch) Rober Boehne (a member of libtool maintainers) says: http://mail.gnu.org/pipermail/libtool/2002-October/006960.html impgen.c bug discussion: http://mail.gnu.org/pipermail/libtool-patches/2002-October/002112.html http://mail.gnu.org/pipermail/libtool/2002-October/007087.html > then is there a stable 1.5 on the way that we will be > able to use instead? No. We will have to wait until 1.4e alpha or 1.5 stable is released. > We are already using autoconf 2.5.2, but we should prepare > to use future versions too. Cygwin people have been working for new DLL building method. They provide the dllhelpers package which demonstrates how to build and use DLLs with recent binutils/gcc. http://www.neuro.gatech.edu/users/cwilson/cygutils/dll-stuff/index.html This demo will be help to understand new method. I was able to build gtkmm2 DLLs by adding -Wl,--export-all-symbols LDFLAGS.
Oops yes, you were right about wrap_init.cc. Sorry about that ! So, this leaves us with the libtool impgen bug only. Maybe Murray could patch its own libtool.m4 ? Another solution would be to patch the libtool script created at configure time, using a sed script (sed would then be a requirement when building on win32). What do you think ?
OK, but I really really wish you would bother the libtool maintainers until they fixed libtool 1.4 properly. I mean, you have already given them a patch for it. I think one of you already provided a patch to do the libtool-patching. I think this is better than remembering to patch our own libtools. Could you repost the patch?
I posted impgen.c patch to libtool-patches ML again.
Murray, libtool people have no intention to fix impgen.c bug in libtool-1.4. We have to fix it by ourselves. http://mail.gnu.org/pipermail/libtool-patches/2002- November/002251.html http://mail.gnu.org/pipermail/libtool-patches/2002- November/002263.html
How bizarre - stopping maintenance of a stable branch before a new stable is available. Could you repost the gtkmm patch that will fix this for us?
Any chance of us getting that patch?
No gtkmm patch is needed for the present (until libtool-1.5 is released :-<). What we should do is * use autoconf-2.52 (libtool's AC_LIBTOOL_WIN32_DLL macro has a problem with >=2.53) * use libtool-1.4.3 with above impgen-bug.patch On my project, gtkglextmm, I use autoconf-2.52, automake-1.6.3, and libtool-1.4.3 with above patch. It can be built successfully under mingw without any changes.
This impgen patch is not required anymore with the latest snapshost of the autotool (libtool, automake, autoconf) development brach in the current cygwin distribution, namely libtool 1.4e automake 1.7.2 autoconf 2.57. DLLs are now built with the g++ -shared command, dramatically decreasing the time required for linking, and import library are installed by default (no more local-install rules in the Makefile.am). Yipee ! When I tried to build gtkmm-2.2 on win32 (using mingw32) I faced two distincts problems though : 1. Some glib/atk/gtk+ functions are no exported in the gtk+-2.2 DLLs though. I reported this on the gimpwin-dev mailing list. I guess it's better to have this fixed in the gtk+-2.0-win32 official binaries instead of adding a bunch of _GTKMMPROC_H_AND_CC(#ifndef G_OS_WIN32) _WRAP_METHOD(...) _GTKMMPROC_H_AND_CC(#endif) in the gtkmm source code. Haven't received any reply to my post though ! 2. In the Atk::Text component (atk/src/text.hg), the text_attributes_changed signal is not available on win32. Unfortunately, wrapping the _WRAP_SIGNAL(...) call with _GTKMMPROC_H_AND_CC does not work in this case because _WRAP_SIGNAL generates multiple code sections in tree.c and tree_p.c. I'm not a m4 specialist, so if somebody could try to fix this in CVS... Cedric
1. If you don't get a reply today, please add a GTK+ bug in bugzilla and make this bug depend on it. This will happen much quicker if you provide a patch for GTK+ yourself. 2. I need to think about this.
I just got an answer from Tor (the win32 gtk+ maintainer). Those missing symbols will be fixed in the next release of gtk+ (and glib/atk). Because he prefer to stick to official release versions instead of intermediate snapshots (to avoid confusion), I guess we will have to live with theses missing symbols in the meantime. I'm going to patch gtkmm to #ifdef those symbols (with _GTKMMPROC_H_AND_CC) and I propose we remove those directives when the next gtk+ is available. Now, when it's done, I can either submit a patch against the current CVS or keep these modifications locally on my PC. That's up to you ! But I still need a solution for the Atk::Text::text_attributes_changed signal !
Always submit patches even if they won't be applied immediately. Are you sure we will need to wait a long time for the next GTK+ release? I'll invesigate the signals-not-needed-on-certain-platforms issue soon.
Ok, I added a _GTKMMPROC_SIGNALS_H_AND_CC to tools/m4/base.m4. I'm testing it right now and will provide a global win32 patch as soon as possible.
Oh, well, here's fairly hacky patch that should do what you want. Maybe your patch is better.
Created attachment 14745 [details] [review] gtkmm_signal_ifndef.patch
Thanks for the patch. The choice is actually up to you. What I did was to write the equivalent of _GTKMMPROC_H_AND_CC for signals : define(`_GTKMMPROC_SIGNAL_H_AND_CC',`dnl $1 _PUSH(SECTION_ANONYMOUS_NAMESPACE) $1 _POP() $1 _PUSH(SECTION_H_DEFAULT_SIGNAL_HANDLERS) $1 _POP() SECTION_H_DEFAULT_SIGNAL_HANDLERS $1 _PUSH(SECTION_PCC_CLASS_INIT_DEFAULT_SIGNAL_HANDLERS) $1 _POP() $1 _PUSH(SECTION_CC_DEFAULT_SIGNAL_HANDLERS) $1 _POP() $1 _PUSH(SECTION_PCC_DEFAULT_SIGNAL_HANDLERS) $1 _POP() $1 _PUSH(SECTION_CC_SIGNALPROXIES) $1 _POP() ')dnl If we use your patch, which adds extra options to _WRAP_SIGNAL, then it would be nice to have the equivalent for _WRAP_METHOD. We would then drop _GTKMMPROC_H_AND_CC. You're the maintainer, so it's up to you !
What does _GTKMMPROC_H_AND_CC do and how does it help? I don't have the source here. Would it just allow you to add the same #ifdef to everywhere that a _WRAP_SIGNAL() puts code? That seems a bit simpler than my repetitive patch.
This is what _GTKMMPROC_H_AND_CC does. # Put these, for instance, around gtkmmproc macros to make the #ifndef appear around the generated code in both the .h and .cc files. # e.g. _GTKMMPROC_H_AND_CC(#ifndef _SUN_CC_) # e.g. _GTKMMPROC_H_AND_CC(#endif //_SUN_CC_) # _GTKMMPROC_H_AND_CC(code) define(`_GTKMMPROC_H_AND_CC',`dnl $1 _PUSH(SECTION_CC) $1 _POP() ')dnl My _GTKMMPROC_SIGNAL_H_AND_CC is just an extension for signals.
Yes, I prefer your solution.
Ok, we have a deal. I'll submit my patch as soon as I can get access to the anonymous gnome cvs server (I get a bunch of "no space left on device" on the server those days).
OK, tell me if the problem continues.
Here is my patch against the current cvs. I also updated the ChangeLog and the README.win32 files. I have gtkmm-2.2.0 binaries ready for mingw32 (along with libsigc++-1.2.3). Do you think it's better to upload those binaries on sourceforge or to have them on a separate web page ?
Created attachment 14773 [details] [review] Win32 patch for gtkmm-2.2
Personally I wouldn't like us to advertise official win32 binaries unless they had a proper windows installer. I think it's fine if they are on your own page. I'm very glad that 2.2 builds on win32 again.
I get this error under linux: SECTION_H_DEFAULT_SIGNAL_HANDLERS I have attached the generated .h file - it contains an unparsed m4 macro. Maybe my checkout is confused. I did this in a hurry.
Sorry, this is the error. That was the macro. In file included from component.cc:27: ../../atk/atkmm/object.h:359: syntax error before `::' token ../../atk/atkmm/object.h:376: syntax error before `::' token gmake[4]: *** [component.lo] Error 1 gmake[4]: Leaving directory `/root/cvs/gnome2/gtkmm2/atk/atkmm' gmake[3]: *** [all-recursive] Error 1
Created attachment 14809 [details] object.h from atkmm
Oops, indeed there is a typo in tools/m4/base.m4 in the _GTKMMPROC_SIGNAL_H_AND_CC I have added. The SECTION_H_DEFAULT_SIGNAL_HANDLERS line should not be there. the result of a bad copy/paste probably. The macro becomes ----------- $1 _PUSH(SECTION_H_DEFAULT_SIGNAL_HANDLERS) $1 _POP() <!-- Remove this section --> SECTION_H_DEFAULT_SIGNAL_HANDLERS <!-- Up to this point --> $1 _PUSH(SECTION_PCC_CLASS_INIT_DEFAULT_SIGNAL_HANDLERS) $1 _POP() --------- I'm deeply sorry but of course this error did not show up on WIN32 !
Wonderful. Applied.
I must remember to apply this to gtkmm 2.4 too.
Applied to 2.4.