Re: gettext patches for cygwin #1: rdata

[Charles Wilson]

Bruno Haible wrote:
> 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).

True.

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

You are correct.  I had no difficulty with long_options[] that contained 
only constants.  I was being preventative, rather than curative, there. 
 I figured that it was better to have all the application code "look" 
the same, so that IF somebody later added a flag that took a value, they 
wouldn't have to remember to also change 'const' to 'FUNKY_CONST_MACRO'. 
 Or worse, forget make the change at all (because it has no effect on 
linux/unix and nobody notices) so a new release came out that was broken 
on mingw/cygwin/win32.

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

^^^ not applicable.

> [snip list of files]
> In these cases, the long_options[] array does refer to variables that
> reside in shared libraries. 

Correct.

This is a **slightly** different issue than the typical 'access stuff 
from a DLL'.  This is 'access stuff from a DLL, using a pointer that is 
declared const [even if only indirectly declared const via enclosing 
struct const-ness], and so is placed in non-writable memory and can't be 
fixed up after process load'[*].  That's why it was a separate patch 
from my #4.

[*] This affects "regular" pointer variables if they are const and at 
file scope in the caller app (function scope vars are not placed in the 
.rdata section, even if const).  The problem not limited to 
long_option-type situations.

It's the 'const-ness' of the pointer variable that must hold the 
relocated address of the imported data that causes the problem, not 
whether the data is imported via canonical declspec(__dll[ex|im]port), 
or via auto-import.

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

You keep going on about 'valid ANSI C code'.  I'm wondering what that 
has to do with tea in China?  It may be valid, but as coded in 0.14.5, 
on win32, building shared, *it does not work*. It compiles, links, but 
fails to run. It doesn't matter if it's valid C code; it's an 
acknowledged deficiency of the Win32 platform and good luck getting Bill 
to fix it.  We're stuck with workarounds of various kinds.

> 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 

Sure -- but in the po case you ALSO made it so that ALL platforms use 
the functional form of po_gram_error[_at_line] and NOT the macro.  This 
goes back to my patch #4: I got rid of the macro for Cygwin.  In CVS, 
you got rid of the macro for all platforms.  You also added explicit 
declspec() stuff...in which case you probably could've kept the macro!

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

With regards to the long_options stuff, DLL_VARIABLE magic isn't helping 
you in this particular case, even when applied to the target variable 
(line_comment) imported from the DLL.  Really, you're relying completely 
on the g++/gcc replacement to solve that issue (because compiling with 
g++ would "solve" the problem even if line_comment were not 
DLL_VARIABLE; auto-import would activate, and 'line_comment' itself is 
not a "complex" variable).  Since g++ delays initialization, it knows to 
"ignore" the 'const' on the long_options[] declaration and NOT put the 
structure into .rdata.

I'm explicitly saying 'don't make long_options[] const on these borked 
platforms'.

So what's the diff?

Plus, your use of g++ has the ABI issues I mentioned in the earlier 
message, although here it doesn't matter (since we're compiling the 
"main" app code in each case, and not a library that would be used by 
borland/intel/msvc/etc).  But you're still relying on Murphy staying 
away from your Rube Goldberg, IMO.

> The current gettext CVS already contains the modifications for mingw.
> It'd be nice if the same approach could be used for cygwin.

It probably could.  But I don't think it *should* -- or rather, I 
shudder at using the scaffolding in CVS on EITHER mingw or cygwin. :-)

--
Chuck

P.S. in case it's not clear, thank you for your attention to my submissions.