gcc 3.3.3, const symbols and shared libraries

[Jani Tiainen]

Norton Allen wrote:
> Gerrit P. Haase wrote:
> 
>> Norton Allen wrote:
>>
>>> I have seen the discussions at
>>>
>>> http://sourceware.org/ml/cygwin/2004-09/msg01101.html
>>>
>>> referenced at
>>>
>>> http://cygwin.com/ml/cygwin/2005-03/msg00048.html
>>>
>>> regarding gcc 3.3.3's placement of const symbols into
>>> rdata which then cannot be properly initialized.
>>> This problem seems pretty fundamental. Can anyone
>>> tell me whether there has been any followup to
>>> this? Is it considered a cygwin problem or a
>>> gcc problem? Has it been addressed in 3.4.1?
>>> What are developers doing? Going back to 3.3.1?
>>
>>
>>
>> The rule is to not use const symbols in shared libraries
>> if they are not really const;)
> 
> 
> What do you mean by "really?" These are const from
> the standpoint of "defined once and never changed
> thereafter," but they are not finally defined until
> the link against shared libraries.

Well, it is pointer and defined once and changed never there after... 
But they are initially defined when library is built, but then changed 
once you load application that is linked against library. So you 
actually end up having it initialized twice.

Note that C(++) doesn't have concept of uninitialized data. All data is 
initialized to some (known) value at the time of compile.

> It's currently an issue because it requires changes
> to quite a few packages. In the past week, I had to
> remove const declarations from glib-2.6.3 and
> gtk+-2.6.4 to get them to compile. Are these changes
> that are uniquely required by cygwin, or are these
> going to be required for all gcc platforms?

This is problem of Windows platform and GCC...

In windows newest GCC puts constants in RDATA section, which is _read 
only_ for /application/. But because you have pointer to a data which 
should be changed (initialized) after relocation it should be writable 
by /application/.

So this is actually one of those PITA features of Windows platform, and 
there is little you can do.

Actually GCC should be smart enough to make decision about is "const" 
really a constant or a pointer to a data and change location of constant 
  (in Windows platform. I don't think this applies to anywhere else). 
But until it GCC can do something like that, best way is to not to have 
"constant" variables that are not really constants in shared libraries.

-- 

Jani Tiainen


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/