GNOME Bugzilla – Bug 91033
gtkmm2 win32 compile errors
Last modified: 2004-12-22 21:47:04 UTC
gtkmm2 compilation has some problems with MinGW/Cygwin environment. 1. The compilation fails at libpangomm link stage, because libtool cannot generate the import library of libglibmm DLL. The cause is a limitation of impgen.exe utility of libtool 1.4.2. impgen.exe cannot treat the anonymous namespace symbols correctly. It can be solved by removing all anonymous namespaces. 2. Some sources need to be fixed. * gtk/gtkmm/menu_elems.cc compilation fails at line 28, because strings.h doesn't exist. * libgtkmm link fails, because gtk/gtkmm/wrap_init.cc includes Plug and Socket codes. They are not supported under win32 platforms. 3. 'make install' fails, because it doesn't install the import libraries. For example, glib/glibmm/Makefile.am should include the following targets. if OS_WIN32 install-libtool-import-lib: $(INSTALL) .libs/libgdkglextmm-1.3.dll.a $(DESTDIR)$(libdir) uninstall-libtool-import-lib: -rm $(DESTDIR)$(libdir)/libglibmm-1.3.dll.a else install-libtool-import-lib: uninstall-libtool-import-lib: endif install-data-local: install-libtool-import-lib uninstall-local: uninstall-libtool-import-lib
Have you looked at README.win32. Do you have any idea why it works for Cedric Gustin?
Yes. I've looked at README.win32, but I cannot figure out why it works. I think the information is old. libtool 1.4.2 is recommended in README.win32, but it has the anonymous namespace problem. Maybe Cedric Gustin uses latest version of libtool which comes with the Cygwin distribution. Anyway, autotools used by current gtkmm2 supports Win32 DLL. If the problems I reported will be fixed, we can build win32 DLL from original source distribution without any modification.
I don't understand. Are you saying that there is no problem with the tarball, but only when building from CVS?
I'm saying about the gtkmm2 source tarball. We cannot build win32 DLL from current (1.3.20) source tarball without any modification. gtkmm-1.3.20 source tarball has some problem.
OK. I was confused by this sentence "Anyway, autotools used by current gtkmm2 supports Win32 DLL."
autoconf 2.52 and libtool 1.4.2 support win32 DLL, but gtkmm2 source tarball is not fully maintained to be successfully compiled under MinGW/Cygwin environment.
1. Naofumi is right. There is an impgen related bug in libtool. It was mentioned some time ago on the mingw list and forwarded to libtool-devel if I remember correctly. I has not been fixed (to my knowledge) since then. Turns ou mingw32 has never been correctly supported by libtool. I fixed this impgen bug on my local copy of libtool-1.4.2 before I started working on the port of gtkmm on win32. That's the reason why I forgot to mention this fix and potential problem in the README.win32. In the impgen.c source code contained in either the generated libtool or (better) your local copy of libtool.m4, replace the following line printf ("\t%s @ %ld ;\n", erva+name_rva, 1+ i); with this one printf ("\t\"%s\" @ %ld ;\n", erva+name_rva, 1+ i); Note the \s argument now enclosed in "". 2. I'm working with the cvs code in maintainer mode. I also experienced this wrap_init problem when building from the source distribution. There are two possible solutions : the first one is to build wrap_init.cc at compile time (and include it in the dist-clean list). The second is to modify the perl code that generates it and to include #ifdef OS_WIN32 ... #endif around plug and socket related functions. 3. Import libraries are not installed because on cygwin (which, unlike mingw32, is a little less "unsupported" by libtool) uses direct auto-import from DLLs. I usually copy those libraries by hand to their final destination but you're right, maybe it's better to add some local Makefile.am rules. As I said many times in the "gtkmm should build on win32" bugzilla thread, building on win32 using the autotools is not straightforward at all. The maintainer of the gtk+ port of win32 gives little information about building glib, pango, atk anf gtk+ on win32 and strongly recommends to use the prebuilt binaries. You now know the reason why !!! Cedric
1. I think autogen.sh should do the impgen.c code fix when we are using libtool 1.4.2. # fix impgen.c bug of libtool 1.4.2 mv aclocal.m4 aclocal.m4.bak cat aclocal.m4.bak | sed -e 's|printf (\"\\t%s @ %ld ;\\n\", erva+name_rva, 1+ i);|printf (\"\\t\\"%s\\" @ %ld ;\\n\", erva+name_rva, 1+ i);|' > aclocal.m4 2. I think the better solution is to build wrap_init.cc at compile time, and we should keep the perl codes simple.
1. I would like to see a URL of the libtool bug/patch report. 2. This makes gtkmm depend on perl again. I would like to avoid that if possible. I believe we already have some macro like NO_WRAP which keeps stuff out of wrap_init.cc. We could create an extra macro for win32. 3. Please submit a patch. Regarding not being able to build GTK+ easily from source - I think that's a major problem.
Created attachment 10564 [details] [review] install-import-lib.patch
Created attachment 10565 [details] [review] native-struct.patch
1. Sorry. I don't know the location of the libtool bug report. 2. OK. I understand. Compile-time perl dependency couldn't be so nice. 3. I've created two patches for the latest gtkmm-1.3 CVS source. install-import-lib.patch : fix 'make install' to install win32 import libraries. native-struct.patch : add -fnative-struct CXXFLAGS for native win32 target.
1. Maybe it hasn't been fixed because it has not been submitted as an official bug, or because nobody has not chased it up. This seems to be the obvious solution here. 2. I'll try to do this soon. 3. Always patch the ChangeLog. I will not commit patches without ChangeLog entries. Cedric, do you like these patches? You are almost the win32 gtkmm maintainer.
3. Sorry. I submit new patches include ChangeLog.
Created attachment 10584 [details] [review] install-import-lib.patch
Created attachment 10585 [details] [review] native-struct.patch
2. I would suggest getting rid of strings.h header inclusion at line 28 in gtk/gtkmm/menu_elems.cc. I think there's no need to include it.
In the ChangeLog you should say _why_ you added the native-struct thing.
Cedric, please take a look at these.
Sorry for the delay but bugzilla was down yesterday : 1. Couldn't install-import-lib.patch be rewritten as a generic file (that uses sublib_name) to be put in the build_shared directory and included in the various Makefile.am's ? Naofumi, you seem to be fairly automake/conf litterate, so I suppose this shouldn't be too much of a problem for you ! 2. The -fnative-struct enables MSVC-style bit field packing on win32 platforms and is required when compiling applications that use the win32 native port of gtk+. I guess the native-struct.patch can be applied to CVS as long as we keep in mind that, one day or another, we'll have to consider the case of gcc-3.x where the -fnative-struct flag has been renamed to -mms-bitfields. Cedric
1. I submit new install-import-lib-2.patch. What do you think of it? 2. It is not difficult to write m4 macros for checking whether g++ accepts new -mms-bitfields option or not.
Created attachment 10638 [details] [review] install-import-lib-2.patch
Cedric, regarding the native-struct thing, how were you able to build this before?
-fnative-struct was set manually using CXXFLAGS="-fnative-struct -O2 -g" ./configure ... -fnative-struct is an explicit requirement (as stated in the gtk+- 2.0/README.win32 and on the www.gimp.org/win32/ website) when compiling a library and/or application that uses the native port of gtk+ on win32. If you don't use the -fnative-struct, you get a (also very explicit) error window when you launch your gtk+/gtkmm application. gtkmm cvs patched with install-import-lib-2.patch is compiling right now on my machine. The patch seems to be great. What remains to be fixed is this wrap_init.cc business along with the impgen problem.
Both patches applied. Thanks - great work. I will look at the wrap_init.cc thing soon if noone else does. I think we have a similar thing already. You MUST first try to solve the libtool bug by talking to the libtool people.
This is the impgen.c patch for libtool. Cedric, could you please try it? If this patch works well, I'll post it to the libtool mailing list.
Created attachment 10652 [details] [review] libtool-1.4.2-impgen.patch
Created attachment 10653 [details] [review] libtool-cvs-20020823-impgen.patch
1. Libtool patches are Ok. 2. Because libgtkmm_generate_extra_defs does not use the generic Makefile.ams from build_shared, its import library is currently not installed in the target directory. I can fix this but the anonymous CVS is not in sync with the main CVS tree yet and, hence, does not contain the patches that Murray applied yesterday night. 3. I copied/pasted the install-import-lib modifications to libsigc++- cvs. A similar patch against libsigc++-1.2 is attached. Great work Naofumi !
Created attachment 10659 [details] [review] Import library install patch on win32 for libsigc++-1.2
Created attachment 10695 [details] [review] win32_wrap_init.patch 1
Does this patch (win32_wrap_init.patch 1) fix the wrap_init problem? If not, maybe you can fix it.
Murray, win32_wrap_init.patch works well.
Now, the following problems still remain to be fixed. 1. #include <strings.h> at line 28 in gtk/gtkmm/menu_elems.cc. 2. libtool impgen.c bug. I've submitted a patch to libtool-patches@gnu.org. The following attachment is a simple shell script to fix impgen.c bug in aclocal.m4 or configure script. I think autogen.sh can use it to fix aclocal.m4 generated by aclocal.
Created attachment 10698 [details] fix-impgen-bug.sh
1. Please try to provide a patch for your platform. 2. We will wait for the libtool people.
Created attachment 10707 [details] [review] win32-strings-h.patch
The following patch adds new win32 build instructions. It also contains the fix-win32-impgen.sh script to help win32 build. Now, gtkmm2 can be compiled with the following instructions. $ cp configure configure.bak $ cat configure.bak | ./scripts/fix-win32-impgen.sh > configure $ env CXX='g++ -mpentium' LDFLAGS='-Lc:/gtkmm/lib' \ ./configure --prefix=c:/gtkmm \ --build=i386-pc-mingw32 \ --disable-static $ make $ make install
Created attachment 10708 [details] [review] win32-build-inst.patch
win32-strings-h.patch applied. Please try to provide cvs patches in future - see the instructions on gtkmm.org. win32-build-inst.patch: No, I have said twice now that we will wait for the libtool people first. We can point people to your libtool patch in the meantime. Please separate that from your patch. If our build instructions are not complete, then please patch README.WIN32.
OK. I'm going to put off the impgen problem until libtool is fixed. Now nothing remains to be fixed. I think this bug should be closed.