Menu
▾
▴
mingw-msys
|
From: Patrice St-G. <pa...@us...> - 2011-01-19 05:43:58
|
Hi list, I am trying to port a Gtk/OpenGL app to Windows (geomorph.sourceforge.net). I first installed the MinGW - Msys current bundle in a WinXP SP3 VM (mingw-get-inst-20101030.exe). Then I installed separately, in the /mingw directory, the GTK win32 packages (http://www.gtk.org/download-windows.html). I first tried to install the GTK bundle in a distinct directory, but I got some library conflicts, which ended with seg faults in internationalization functions (bindtextdomain). I was able to compile my app with ./configure and make, after some reordering of the libraries in the linking command. Autoconf / automake broke the configure script, so I avoided them. Now when I execute geomorph.exe from the MSYS shell I get a seg fault in printf. A test with "printf("Hello World!\n");" worked perfectly, though. After searching the Mingw / Msys forums and the web a few evenings, I give up! The linking command is: gcc -v -g -O2 -o geomorph.exe -Lc:/MinGW/msys/1.0/lib -Lc:/MinGW/lib main.o app.o document.o doctype.o thisappinit.o stack.o ../hf/libhf.a ../fourier/libfourier.a ../utils/libutils.a -lgdk-win32-2.0 -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgio-2.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl -lglu32 -lopengl32 -luser32 -lkernel32 -lgtkglext-win32-1.0 -lgdkglext-win32-1.0 -lpng14 -lmsvcrt -lm &> gcc.txt The backtrace in GDB is: Starting program: C:\MinGW\msys\1.0\home\Patrice_St-Gelais\geomorph-0.61\src\app/geomorph.exe [New Thread 2064.0x86c] Program received signal SIGSEGV, Segmentation fault. 0x7c928fea in ntdll!RtlpWaitForCriticalSection () from C:\WINDOWS\system32\ntdll.dll (gdb) backtrace #0 0x7c928fea in ntdll!RtlpWaitForCriticalSection () from C:\WINDOWS\system32\ntdll.dll #1 0x7c91104b in ntdll!RtlEnumerateGenericTableLikeADirectory () from C:\WINDOWS\system32\ntdll.dll #2 0x0009bb0c in ?? () #3 0x71064c08 in msys-1!cfsetispeed () from C:\MinGW\msys\1.0\bin\msys-1.0.dll #4 0x7105f964 in msys-1!ctermid () from C:\MinGW\msys\1.0\bin\msys-1.0.dll #5 0x7108eb6e in msys-1!_ctype_ () from C:\MinGW\msys\1.0\bin\msys-1.0.dll #6 0x00000000 in ?? () From what I have read on the web and in the system headers, the problem is probably related to an internationalisation library which redefines printf. Msys provides /mingw/msys/1.0/lib/libintl.dll.a (gettext 0.17?), Mingw also (/mingw/lib/libintl.dll.a) but they are not the same size, and Gtk provides /mingw/bin/intl.dll (gettext 0.18!). How can I compile and link an internationalized program with Msys? Should I have ever tried at first? Any help to sort that mess is welcome! Thanks Patrice |
|
From: Charles W. <cwi...@us...> - 2011-01-19 21:59:54
|
On 1/19/2011 12:43 AM, Patrice St-Gelais wrote: > I am trying to port a Gtk/OpenGL app to Windows (geomorph.sourceforge.net). > > I first installed the MinGW - Msys current bundle in a WinXP SP3 VM > (mingw-get-inst-20101030.exe). So far, so good. > Then I installed separately, in the /mingw directory, the GTK win32 > packages (http://www.gtk.org/download-windows.html). I first tried to > install the GTK bundle in a distinct directory, but I got some library > conflicts, which ended with seg faults in internationalization functions > (bindtextdomain). Err...hmm. This should *probably* work, but I fear you may still be running in to library conflicts. You need to understand how static libs, import libs, and DLLs are related, and what the naming conventions are. More below. > I was able to compile my app with ./configure and make, after some > reordering of the libraries in the linking command. Autoconf / automake > broke the configure script, so I avoided them. Well, that shouldn't happen unless geomorph uses VERY old versions of the autotools which are somehow incompatible with the new version (unlikely) OR if you installed the "msys-tailored" autotools instead of the "mingw-tailored" ones. You *should* have a ton of different autoconf-2.xx automake-1.x scripts in your C:/MinGW/bin directory, and C:/MinGW/bin should appear in your $PATH earlier than wherever MSYS is (in your case, it appears to be C:/MinGW/msys/1.0/bin). This is also related to your confusion about gettext; there are two versions of it, as well. One that is msys-tailored, and one that is mingw-tailored. (And when I say "tailored" I mean: tailored to be used when creating libraries and apps for a specific platform. Since you want to create mingw libs and apps -- and are only using msys as a "host" environment -- you want to be sure to use the mingw-tailored stuff at all times. This is especially important when it comes to binary libraries -- like msys-intl-8.dll (bad!) vs libintl-8.dll (usually good! -- except in your case you want to use the gtk flavored intl.dll instead; it's probably bad if half of your stuff -- the /other/ GTK dlls -- use one version of libintl, but your main app uses the mingw version of libintl. Since you can't "fix" the GTK dlls, you have to ensure your stuff ALSO uses that version of libintl). > Now when I execute geomorph.exe from the MSYS shell I get a seg fault in > printf. > > A test with "printf("Hello World!\n");" worked perfectly, though. My suspicion is you are using the msys-intl-8.dll and your printf is actually printf ( _("some translation string %s"), ...) and _() -- the "please translate me" function provided, via macro definition, by (some flavor of) libintl -- is returning null. And printf doesn't like null format strings. Why would _() return null? Because you're calling the wrong one, from an msys-dependent DLL and not the "correct" one (in your case) from gtk. Also, you now have TWO printf() functions -- one from the regular MSVCRT.DLL runtime and one from the msys-1.0.dll runtime. This is Not Good. > After searching the Mingw / Msys forums and the web a few evenings, I > give up! > > The linking command is: > > gcc -v -g -O2 -o geomorph.exe -Lc:/MinGW/msys/1.0/lib -Lc:/MinGW/lib ^^^^^^^^^^^^^^^^^^^^^^^^ Bad! No cookie! > main.o app.o document.o doctype.o thisappinit.o stack.o ../hf/libhf.a > ../fourier/libfourier.a ../utils/libutils.a -lgdk-win32-2.0 > -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgio-2.0 -lgdk_pixbuf-2.0 > -lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 -lpango-1.0 -lcairo > -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl -lglu32 > -lopengl32 -luser32 -lkernel32 -lgtkglext-win32-1.0 > -lgdkglext-win32-1.0 -lpng14 -lmsvcrt -lm &> gcc.txt > > The backtrace in GDB is: > > Starting program: > C:\MinGW\msys\1.0\home\Patrice_St-Gelais\geomorph-0.61\src\app/geomorph.exe > [New Thread 2064.0x86c] > > Program received signal SIGSEGV, Segmentation fault. > 0x7c928fea in ntdll!RtlpWaitForCriticalSection () > from C:\WINDOWS\system32\ntdll.dll > (gdb) backtrace > #0 0x7c928fea in ntdll!RtlpWaitForCriticalSection () > from C:\WINDOWS\system32\ntdll.dll > #1 0x7c91104b in ntdll!RtlEnumerateGenericTableLikeADirectory () > from C:\WINDOWS\system32\ntdll.dll > #2 0x0009bb0c in ?? () > #3 0x71064c08 in msys-1!cfsetispeed () > from C:\MinGW\msys\1.0\bin\msys-1.0.dll > #4 0x7105f964 in msys-1!ctermid () from C:\MinGW\msys\1.0\bin\msys-1.0.dll > #5 0x7108eb6e in msys-1!_ctype_ () from C:\MinGW\msys\1.0\bin\msys-1.0.dll See, this is a problem. If you are porting to "mingw" you definitely should NEVER see a function call to MSYS. I suspect this is being pulled in, indirectly, via the (MSYS) libintl. > #6 0x00000000 in ?? () > > > From what I have read on the web and in the system headers, the problem > is probably related to an internationalisation library which redefines > printf. No, I suspect geomorph's source code is properly i18n-ized and uses the _() macro to force a call to gettext() or libintl_gettext(). > Msys provides /mingw/msys/1.0/lib/libintl.dll.a (gettext 0.17?), This is the *import library* used to link against the (msys) libintl DLL, which is /mingw/msys/1.0/bin/msys-intl-8.dll. You don't want that. > Mingw > also (/mingw/lib/libintl.dll.a) but they are not the same size, This is the *import library* used to link against MinGW's libintl DLL, which is /mingw/bin/libintl-8.dll. You probably don't want this, as explained above. > and Gtk > provides /mingw/bin/intl.dll (gettext 0.18!). You probably want to locate the *import library* for Gtk's intl.dll, and copy it into /mingw/lib/ in place of the existing libintl.dll.a. But that would be fragile if you ever upgraded the *mingw* libintl-dev-mingw32 package, since it would install the upgraded mingw libintl.dll.a file on top of your gtk version. FYI: static libraries are *generally* but not always named "foo.a" on mingw; import libraries are *generally* named "foo.dll.a" but there are some, associated with standard Win32 API dlls like kernel32.dll that end in just ".a" Alternatively, you could install all of the GTK stuff in a separate tree, like you did the first time, AND make sure that LDFLAGS and CPPFLAGS contain the appropriate -L -I paths to ensure that the GTK stuff is found "before" the mingw stuff. You'll still have to ensure that you "have" the import library for gtk's intl.dll, and put it in the $myprefix/lib/ directory with the name "libintl.dll.a" -- but this way you won't be "clobbering" the existing mingw version. Never EVER add the msys paths to your search. With regards to the "autotools" you'll want to install mingw-get install mingw32-autotools (but that is pulled in automatically as part of mingw-dtk) You probably *don't* want msys-system-builder or msys-auto*/msys-gettext/msys-libtool, but as long as you ensure your $PATH finds the mingw versions first, it shouldn't hurt if you do have those msys-tailored tools installed. -- Chuck |
