Re: [Mingw-users] advice needed

[Tor L. <tm...@ik...>]

> I downloaded some of the Gnuwin32 libraries.  I think I got
> libintl and readtext from there.  Downloaded the gtk libraries from the
> gtk.org site.

At least the GTK+ Windows binaries on ftp.gnome.org (provided by me)
(which are those linked to from www.gtk.org) work nicest with the
build of gettext-runtime (i.e. intl.dll) (also built by me) also on
ftp.gnome.org, in
http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/  I won't
link to the actual files. Look for the latest version there, at this
moment "0.17-1".

If the application you are building isn't localised itself, or if your
user base uses English anyway and doesn't care for localised messages,
you can simplify application deployment a little bit by using the
"proxy" libintl and not having to distribute intl.dll. Check for the
latest proxy-libintl package in the same folder. proxy-libintl is a
small library that checks only at run-time of the libintl DLL
(intl.dll) is available and if yes, forwards the calls to it, but if
not, acts as a dummy (provides no translations).

> #define libintl_printf printf, but you'd think libintl_printf wouldn't be
> undefined.  Read it was a problem between a version of libintl and another
> library (maybe readtext).  Suggestions on how to correct this permanently or
> which versions of libraries to use to avoid the problem would be appreciated.

I have never personally understood why the GNU libintl.h wants to muck
with the printf functions and provide its own implementation. Well
actually, I think I do understand, it is so that translators can rely
on positional printf parameter support being present. Still, it is
kinda ugly to redefine printf etc in libintl.h

(One benefit of using proxy-libintl is that its libintl.h does none of
that printf business...)

> Also, is it better to build executables on Windows with dlls or build as all
> one executable?

If you have total control and build the entire software stack below
your app yourself, and are capable of building everything statically,
and the application is such that it's logical for just one executable
to be what the end-user runs, then fine, do it.

Otherwise, don't be afraid of DLLs. They aren't that much scarier than
shared objects on Linux or other Unixes.

--tml