Skip to content

DEFUNCT: Use https://github.com/frida/proxy-libintl instead. Trivial minimal wrapper around a dynamically loaded libintl (from gettext)

License

Notifications You must be signed in to change notification settings

centricular/proxy-libintl

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Project forked from https://github.com/frida/glib/tree/master/proxy-libintl

This is a trivial minimal library intended to act as a proxy for a
dynamically loaded optional libintl. This dynamically loaded library
would be intl.dll (the core DLL of GNU gettext-runtime) on Windows,
libintl.dylib on MacOS, and libintl.so on many embedded (?)
platforms. It is relevant on Windows, MacOS and some embedded
platforms. On Linux you have gettext functionality already in the C
library.

If you compile it with -DSTUB_ONLY the ability to dynamically load
libintl is not compiled in, and this library always acts as just a
dummy.

The STUB_ONLY patch was provided by Geoffrey Wossum, thanks.

proxy-libintl was originally intended to be used when building
software that wants to use i18n features of (GNU) gettext, but one
wants to be able to decide only at package/installer construction time
whether to actually support i18n or not. In the negative case, one
wants to avoid having to ship the gettext DLL (intl.dll) at all. With
the -DSTUB_ONLY possibility one can also use it when one has no
intention to provide even the possibility of localisation in the
binaries one builds against this.

When building Windows DLLs with gcc, if you don't use a .def file and
don't use __declspec(dllexport) attributes either to declare the list
of exported functions, GNU ld will export all global symbols. Usually
this is what you want, as it corresponds closely to what happens on
ELF-based platforms like Linux.

However, when you build such a DLL, let's call it libfoo, against the
static proxy-libintl, this then means that the libintl entry points
will also get exported from the libfoo DLL. This is definitely not
what you want. It might then lead to other DLLs higher up in the
dependency stack to import the libintl functions from the libfoo DLL.

To avoid this, use the --exluce-libs ld flag, i.e. pass
-Wl,--exclude-libs=libintl.a in your LDFLAGS when building
libfoo. Unfortunately there is no __declspec(nodllexport)...

Both a "plain" 32-bit library and a x86_64 one is provided.

Tor Lillqvist <tml@iki.fi>, July 2008