This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: gnome 2.8.0 and external dependencies
- From: "Gerrit P. Haase" <gp at familiehaase dot de>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 3 Oct 2004 10:52:25 +0200
- Subject: Re: gnome 2.8.0 and external dependencies
- Organization: Esse keine toten Tiere
- References: <274233419.20040915234721@familiehaase.de><4151E33F.9090601@users.sourceforge.net><1776831425.20040923002131@familiehaase.de><4157A4FA.2020202@users.sourceforge.net><1076317072.20041003020000@familiehaase.de><415F84BC.1040603@cwilson.fastmail.fm>
- Reply-to: "Gerrit @ cygwin-apps" <cygwin-apps at cygwin dot com>
Hello Charles,
Am Sonntag, 3. Oktober 2004 um 06:49 schriebst du:
> 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?
Yes, cool. Now I think I can distinguish between 'wrong' and valid
const struct definitions. May I consider using 'const' for structs
which are not really constant (i.e. containig a variable) as harmful?
Gerrit
--
=^..^=