Re: gcc 3.3.3 builds "corrupt" lesstif-0.93.94

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

Danny Smith wrote:
> Back before .rdata was enabled for user data in GCC, const data was
> put into ,text, which is normally readonly as well. But this, in
> pe-dll.c:pe_create_import_fixup
>
> line 2178
>
>       /* If we ever use autoimport, we have to cast text section
> writable.  */
>       config.text_read_only = FALSE;
>       output_bfd->flags &= ~WP_TEXT
>
> allowed it to work.  .

Good info.  Thanks -- I'll try to code up a similar patch (but the 
"obvious" symbol certainly doesn't exist currently, and 
"config.rdata_read_only" is *really* going to look funny.  I can see it 
now on the binutils list: "Why do you want a flag that indicates whether 
the read-only-data section is read-only?"

> So checking one or both of these flags provides info on whether
> we might also need to make .rdata writeable.
>
> Me?  I would just do something simple like mark the problematic data as
> dllimport.  I don't
> like the idea of making .text writeable, let alone .rdata

I don't think that would work.  Take this earlier example:

const struct poptOption options[] = {
     ...
     {"version", 'v', POPT_ARG_NONE, &cl_output_version, 0,
      "Output compiler version and serial", NULL},
     ...
}

In this example, it is cl_output_version that is dllimported from a DLL. 
 But it's options[] that is in .rdata, and contains the reference to 
cl_output_version.  By explicitly dllimporting cl_output_version, you 
still don't solve the problem of "options[0].value" being stored in a 
non-writable section. [Unless dllimport somehow instructs the *windows 
loader* to do the magic properly, before the "non-writable" thing is 
enforced -- kinda like my original hope for "our" machinery, but which 
might happen even earlier in the whole process.  I'm not sure about this]

Plus, there's another problem: variables imported from a DLL are usually 
declared by the library's header file.  So, if (somehow) declaring 
cl_output_version as dllimport would fix this rdata problem, you still 
have now forced us back to the Bad Old Days before auto-import. 
Because now, in order to support this wierd corner case (a CLIENT app 
wants to stick the address of a dll-imported variable into a data 
structure that is marked const, and is thus stored in .rdata) you 
require that the LIBRARY declare that symbol using the old magic 
DLLIMPEXP-style macros, which expand to declspec(dllimport) when 
building a client (and, presumably, declspec(dllexport) when building 
the library itself: this isn't necessary, but its "the way it's done").

And here's the rub: with current binutils, if ONE symbol is declared 
dllexport, then ALL of them must be -- because having ONE symbol 
declared dllexport "turns off" the auto-EXPORT functionality when 
building the DLL.

Your solution "feels" like a step backwards, to me -- even assuming it 
actually solves the problem, which I don't think it will [see three 
paragraphs up].  Yeah, I could test this instead of speculating, but 
it's late.  If someone beats me to it, an ounce of experimental data is 
worth a ton of theory -- go for it.

--
Chuck