bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bruno Haible
Subject: Re: gettext: compilation/link errors (DLL on MinGW/MSYS (Win32))
Date: Tue, 7 Jun 2005 19:46:34 +0200
User-agent: KMail/1.5

Hello,

Mark Junker wrote:
> I've found some errors during compilation of gettext for MinGW/MSYS
> (Win32).

Thanks for the detailed report. I'll gladly take patches if they are good,
since I don't use that platform myself but others do.

> 1. Compilation for C# referencing "GNU.Gettext" doesn't work. On Win32
> platforms, you must specify as "GNU.Gettext.dll" as library
>
> The Makefile.am that's affected is gettext-tools/src/Makefile.am. The
> compilation of msgunfmt.net.exe from msgunfmt.cs must use -l
> GNU.Gettext.dll.

The .dll in the filename exists on all platforms, but apparently some
C# compilers add the .dll suffix and some don't. The script that shall
ensure portability across all C# compilers is
gettext-tools/lib/csharpcomp.sh.in. Can you modify it so that it works
with your C# compiler?

> 2. On MinGW, the mbrtowc function can only be found in the libmsvcp60
> library.
>
> You have to add -lmsvcp60 on the MinGW/MSYS platform in
> gettext-tools/lib/Makefile.am and gettext-tools/src/Makefile.am to get
> the mbrtowc function. However, the current work-around is to export
> LIBS="-lmsvcp60" but the build process should work out-of-the-box ...

msvcp60.dll is not part of a standard Windows2000 installation. Therefore
it would be not good to distribute binaries linked against this DLL, or to
assume its existence. Instead, an autoconf test should be added to test
for the existence of mbrtowc() in the _standard_ library.

> 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...

> 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.

> 5. When making a "make install", it recurses into
> gettext-tools/examples/hello-c. AFAIK this is an error too because it
> prevents a make install from completion.

Yes, "make install" is not meant to recurse into any of the hello-*
directories. How come? How to fix it?

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]