Re: gettext patches for cygwin #1: rdata

[Bruno Haible]

Charles Wilson wrote:
> If gettext is compiled with gcc of 3.3 or later vintage, many of the
> application programs can not be executed.  This problem is described here:
>
> "Problem running xgettext after compiling gettext 0.14.1 with gcc 3.3.3"
> http://www.cygwin.com/ml/cygwin/2005-02/msg00741.html
>
> And the problem is diagnosed here:
>
> "cygwin, libtool, dlpreopen, and .rdata"
> http://sourceware.org/ml/cygwin/2004-09/msg01101.html

Thanks for this report. I encountered a similar problem on mingw,
appearing with the long_options array in several programs in the
gettext-tools/ directory (but none in the gettext-runtime/ directory).

> Basically, const structs are placed in .rdata by recent gcc's.
> Unfortunately, on cygwin the address fixups for complex data structures
> can't be performed on objects in .rdata -- so if the struct contains a
> reference to another variable (e.g. a long_option struct with the
> address of a target variable in its 'int *flag' field), then the
> application cannot be initialized.

>       * gettext-runtime/src/envsubst.c: use it instead of 'const'
>       in long_options declaration.
>       * gettext-runtime/src/gettext.c: ditto
>       * gettext-runtime/src/ngettext.c: ditto

You needed to patch gettext-runtime/src/*.c ? In these programs, the
long_options array does not refer to variables, only to string
literals. Are you saying that

static const struct option long_options[] =
{
  { "help", 0, NULL, 'h' },
  { "variables", 0, NULL, 'v' },
  { "version", 0, NULL, 'V' },
  { NULL, 0, NULL, 0 }
};

does not compile to correct code in a program on Cygwin? This is
very elementary ANSI C code.

If so, you need to fix that in the Cygwin platform. Either change
gcc to not emit pointers to string literals into .rdata, or fix your
relocation handler for .exe programs.

>       * gettext-tools/src/hostname.c: use it instead of 'const'
>       in long_options declaration.
>       * gettext-tools/src/msgattrib.c: ditto
>       * gettext-tools/src/msgcat.c: ditto
>       * gettext-tools/src/msgcmp.c: ditto
>       * gettext-tools/src/msgcomm.c: ditto
>       * gettext-tools/src/msgconv.c: ditto
>       * gettext-tools/src/msgen.c: ditto
>       * gettext-tools/src/msgexec.c: ditto
>       * gettext-tools/src/msgfilter.c: ditto
>       * gettext-tools/src/msgfmt.c: ditto
>       * gettext-tools/src/msggrep.c: ditto
>       * gettext-tools/src/msginit.c: ditto
>       * gettext-tools/src/msgmerge.c: ditto
>       * gettext-tools/src/msgunfmt.c: ditto
>       * gettext-tools/src/msguniq.c: ditto
>       * gettext-tools/src/urlget.c: ditto
>       * gettext-tools/src/xgettext.c: ditto
> At present, the only solution is to NOT declare such structures const.

In these cases, the long_options[] array does refer to variables that
reside in shared libraries. This too is valid ANSI C code, nothing
wrong in the source code. Am I right guessing that the problem doesn't
occur when you use --disable-shared, i.e. that it is a problem with
the Woe32 DLLs? In this case the solution I chose for mingw32 is to
add a DLL_VARIABLE declaration (in gettext-tools/src/read-po.h and
others) - this tells gcc to insert indirections automatically - and
use g++ instead of gcc - this causes the initialization of the
long_options[] array to be performed at runtime instead of at compile-time.
The current gettext CVS already contains the modifications for mingw.
It'd be nice if the same approach could be used for cygwin.

Bruno