Re: [Mingw-msys] Seg fault on printf when porting a Gtk app from Linux to Windows with MSYS

[Charles W. <cwi...@us...>]

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