This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gnome 2.8.0 and external dependencies


Gerrit P. Haase wrote:

Well, you have a struct that is const, so it "never changes" and new gcc puts the whole struct into .rdata

> static const
> struct poptOption cl_libIDL_callback_options[] = {
> [snip]


But the important part is that INSIDE the struct, one of the "initialized fields" contains the address of a variable. In this case, although you didn't show it, it's the address of the variable into which popt is supposed to store the argument for one of the command line options. E.g. (going from memory)
struct {
option = "--bob"
short_option = "-b"
type = POPT_INTEGER
value = &my_variable <<<<---- right here
helpstr = "blah blah blah"
};
So, what's supposed to happen (from popt's perspective) is that the user types "--bob 12" and popt will parse the "12" and store it into my_variable.


However, my_variable is a DATA export from your DLL (it has to be an export, so that popt can "see" it).

But the address of DATA exports from DLLs is unknown at link time. The Windows Runtime Loader has special code (coupled with declspec(dllexport)/declspec(dllimport)) to fixup this address at runtime. To avoid declspec hell, on cygwin and mingw, the platform, compiler and linker cooperate to do something similar, fixing up the address at runtime to be a function pointer to a trampoline, which eventually "makes it all work".

But it is necessary, in both "normal" windows and cygwin's pseudo-runtime-reloc, to UPDATE the address stored in the struct for &my_variable.

But the struct is in .rdata and its contents cannot be changed at runtime.

Better?

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]