Re: gcc 3.3.3 builds "corrupt" lesstif-0.93.94

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Gerrit P. Haase wrote:

> > There may be non-libtool-related instances where the .rdata issue is 
> > biting someone, but I haven't seen any confirmed reports of that...yet.
>
>
> Yes, I confirm that binaries are broken with or without 
> libtool-devel-latest, i.e. when popt is used and the standard:
>
>  const struct poptOption options[] = {
>      ...
>      {"version", 'v', POPT_ARG_NONE, &cl_output_version, 0,
>       "Output compiler version and serial", NULL},
>      ...
>  }
>
> is used.

I see.  Just to make sure I understand, tho: this only is a problem when 
cl_output_version is imported from a DLL, right?  That is, you *could* 
work around it like this:

const struct poptOption options[] = {
    ...
    {"version", 'v', POPT_ARG_NONE, &a_local_variable, 0,
     "Output compiler version and serial", NULL},
    ...
}
// ... call popt's parsing routines
cl_output_version = a_local_variable
// ... so other stuff with cl_output_version

There are obvious pitfalls here (like what if you need to use 
cl_output_version within a callback during the parse phase), but the 
snippet above will not trip the .rdata issue, right?


The other question is, how is the ".rdata is read only, you can't change 
anything there" enforced?  By whom?  Is this something about the pei-x86 
format that is enforced by the Windows Runtime Loader, or is it simply a 
convention enforced by our startup objects (crt0.o etc)?  If it's the 
latter, then surely we can fix that ("Okay, it's read-only AFTER the 
pseudo-reloc fixups are done").

--
Chuck