A follow-up: I've made some progress!
> > The linking command is:
> >
> > gcc -v -g -O2 -o geomorph.exe -Lc:/MinGW/msys/1.0/lib -Lc:/MinGW/lib
^^^^^^^^^^^^^^^^^^^^^^^^
Bad! No cookie!
Yes.
Most of my problems came from the library conflicts between MSYS and
MINGW or GTK for linking, and also for defining variables like datadir,
localedir and so on.
So I've got an almost working program by following these steps, to
insure that I use mingw/gtk instead of msys when linking and running it,
from the msys or command.com shell:
1- Check the %PATH%, from which the msys $PATH is initialized ("you
ensure your $PATH finds the mingw versions first")
2- Check /etc/fstab in MSYS:
C:\MinGW\ /mingw
3-
./configure --prefix=/mingw
4- Reorder appropriately the linking command (e.g. take the former one
and remove -Lc:/MinGW/msys/1.0/lib).
Now the program does not segfault anymore. It exits on a non-existent
directory, but I should be able to fix it.
Thanks!
Patrice

Thanks Chuck, it's very comprehensive! I got most of the points (I
hope), I'll work with those clues during the next days.
Patrice
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.
(...)
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

Charles Wilson-8 wrote:
>
>> Any pointers on how I can fix this?
>
> Sure -- don't use MSYS-1.0.11. That's *very* old; we're up to 1.0.16
> now. 'Course, we no longer provide a monolithic installer for either
> MinGW or MSYS, so you need to use the 'mingw-get' installer tool, or its
> point-n-click GUI wrapper mingw-get-inst:
>
> http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20101030/
>
> and it should Do The Right Thing for you (e.g. it will install, as
> directed, the necessary components of /both/ MSYS and MinGW). You
> probably want to pick "MinGW" and the "MinGW Developer Toolkit" along
> with the "MSYS Base System". This is easy in the GUI, but if you want to
> use the cmdline tool:
>
> mingw-get install mingw msys-base mingw-dtk
>
> FWIW, I vaguely remember some fix related to 100% CPU on W7, added back
> in the msys-1.0.13 days, I think. So, I'm pretty sure using the new(er)
> MSYS will be a strict improvement for you.
>
You're right, just installed it and it seems to work.
--
View this message in context: http://old.nabble.com/Can%27t-run-any-MSYS-binary-on-Windows-7%2C-64-bit-tp30713897p30715686.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

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

On 1/19/2011 4:12 PM, andrelc wrote:
> I just installed MSYS 1.0.11 on a Windows 7, 64-bit machine. This machine
> has no previous install of MSYS.
>
> Any single executable program from the MSYS suite I launch uses 100% CPU and
> produces nothing. As an example, `ls` and `make -v` produce this situation.
>
> I've also installed MinGW 5.1.6 (been installed for a while) with similar
> tools and `mingw32-make -v` runs just fine.
>
> Any pointers on how I can fix this?
Sure -- don't use MSYS-1.0.11. That's *very* old; we're up to 1.0.16
now. 'Course, we no longer provide a monolithic installer for either
MinGW or MSYS, so you need to use the 'mingw-get' installer tool, or its
point-n-click GUI wrapper mingw-get-inst:
http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20101030/
and it should Do The Right Thing for you (e.g. it will install, as
directed, the necessary components of /both/ MSYS and MinGW). You
probably want to pick "MinGW" and the "MinGW Developer Toolkit" along
with the "MSYS Base System". This is easy in the GUI, but if you want to
use the cmdline tool:
mingw-get install mingw msys-base mingw-dtk
FWIW, I vaguely remember some fix related to 100% CPU on W7, added back
in the msys-1.0.13 days, I think. So, I'm pretty sure using the new(er)
MSYS will be a strict improvement for you.
--
Chuck

Hi,
I just installed MSYS 1.0.11 on a Windows 7, 64-bit machine. This machine
has no previous install of MSYS.
Any single executable program from the MSYS suite I launch uses 100% CPU and
produces nothing. As an example, `ls` and `make -v` produce this situation.
I've also installed MinGW 5.1.6 (been installed for a while) with similar
tools and `mingw32-make -v` runs just fine.
Any pointers on how I can fix this?
Thanks,
André Caron
--
View this message in context: http://old.nabble.com/Can%27t-run-any-MSYS-binary-on-Windows-7%2C-64-bit-tp30713897p30713897.html
Sent from the MinGW - MSYS mailing list archive at Nabble.com.

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

On 1/4/2011 5:23 PM, Whitequilll Riclo wrote:
> From: Greg Chicares
>> The general advice is not to use rxvt. It's unmaintained,
>> so its shortcomings won't be fixed. If you want a terminal
>> emulator, consider mintty, which is actively maintained.
>
> So why is rxvt in the msys package if its unmaintained?
Well, the MinGW/MSYS *package* of rxvt is maintained -- by me. But
upstream, the "rxvt" people, dropped off the planet. So, MinGW/MSYS
rxvt is, in one sense, "maintained" enough to keep it in the distro
since many people are used to it and continue to use it. But, in another
sense, it's unmaintained and is a dead-end tool, and we recommend that
new users NOT pick up a bad habit -- and old users kick the habit as
soon as they can.
mintty is much better anyway.
Consider the msys-rxvt package "deprecated" rather than "unmaintained"
if that makes more sense to you.
--
Chuck

On 2011-01-04 21:21Z, Edward Diener wrote:
> What is rxvt
A terminal emulator.
> and what is the difference between the Msys icon and the
> Msys icon with rxvt ?
The general advice is not to use rxvt. It's unmaintained,
so its shortcomings won't be fixed. If you want a terminal
emulator, consider mintty, which is actively maintained.