Re: gettext: compilation/link errors (DLL on MinGW/MSYS (Win32))

[Bruno Haible]

Mark Junker wrote on 2005-06-08:
> The C# compiler is csc from the Microsoft .NET framework. The attached
> patch (gettext_csharpcomp.sh.in.patch) should fix it.

Thanks, I'm applying this patch, and the corresponding modification to
csharpcomp.c.

> The current test only requires that it's defined in the header files.
> The .m4 file where this test is defined comes from gnulib. However, I
> attached a patch (gettext_usable_mbrtowc.patch) that adds the compile &
> link test and modified the sources to check for HAVE_USABLE_MBRTOWC ...

I have instead fixed the mbrtowc.m4 file in gnulib and gettext, so that it
doesn't set HAVE_MBRTOWC when the mbrtowc() function is not available in the
default library.

> BTW: I saw at several places some tests like #if HAVE_MBRTOWC or #if
> !HAVE_MBRTOWC. Those tests may fail with some preprocessors when
> HAVE_MBRTOWC isn't defined.

This is an urban legend. All C and C++ preprocessors since at least 1990
evaluate undefined symbols in #if expressions to the value 0.

> >>3. -lc must not be used on the MinGW platform
> >>
> >>The libc simply doesn't exist on MinGW. This affects
> >>gettext-tools/lib/Makefile.am and gettext-tools/src/Makefile.am.
> >
> >Unfortunately, if I remove the "-lc", we get linker errors on different
> >platforms (like AIX, OSF/1 or BeOS, IIRC). Yeah, libtool...
>
> For a current work-around, I changed configure.ac to set the LIBS_LIBC
> depending on the target type and replacing it in the Makefile.am files.
> The patch is gettext_conditional_libc.patch.

Strangely, I can compile GNU libiconv with -lc on 2 of 3 MinGW platforms
(using Debian's mingw cross-compiler, and using Cygwin with "gcc -mno-cygwin")
without problems. Likewise with GNU gettext and 1 of 3 MinGW platforms.
So I don't see why I should apply this patch.

> >>4. Accessing variables in shared libraries
> >>
> >>The auto-import for variables from DLLs can fail on the MinGW (Win32)
> >>platform when you:
> >>- query the variables address (causes an exception fault)
> >>- use something like "plural_table[i].lang", the auto-import simply fails
> >>
> >>I attached a patch that fixes this problem.
> >
> >These are extensive modifications for code that should work perfectly fine
> >when you compile with --disable-shared. The MSVC port uses a different
> >workaround: compile the files
> >  po-error.c
> >  format.c
> >  msgmerge.c
> >  xgettext.c
> >  msgattrib.c
> >  msgcat.c
> >  msgcomm.c
> >  msgconv.c
> >  msgen.c
> >  msgfilter.c
> >  msggrep.c
> >  msguniq.c
> >in C++ mode. Does this workaround also work with mingw? To put it in
> > place, you would only need to add "-x c++" to a few CFLAGS settings.
>
> I tried it but I had to fix much source code that's invalid in C++.
> Maybe those "fixes" are interesting for you too? I'll send the patch to
> you directly (has a size of > 140k).

You apparently attempted to compile all of GNU gettext with a C++ compiler.
This is overkill. It is sufficient to compile the 12 mentioned source files
in C++ mode. I have now committed the corresponding Makefile.am modifications
- no source code changes! - to the gettext CVS.

> BTW: It seemed that you updated (changed?) the "readlink.c" file. It
> gets compiled even when HAVE_READLINK is not defined.

Yes, the --enable-relocatable mechanics compiles readlink.c on all platforms;
therefore it contains a HAVE_READLINK test.

> "make install" doesn't recurse into the hello-*
> directories. The problem is that it cannot create all those .po files
> required to execute the install-data-local rule in the
> examples/Makefile.am. Where can I find those .po files?

These are usually contained in a distribution tarball (created when I do
"make dist").

> BTW: autoconf/automake complained about a missing AM_PROG_CC_C_O in
> gettext-runtime/configure.ac and gettext-tools/configure.ac. Any idea
> why this is needed?

libtool needs it. But automake has this macro.

> Another problem is that libtool support for MinGW/MSYS is badly broken
> and the maintainer is very unfriendly :-(

Strange. With libtool-1.5.14 on mingw, I had only one single problem so far,
and when I reported it, I got a very friendly reply from a libtool maintainer
(Ralf Wildenhues).

Bruno