Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
To:	cygwin AT cygwin DOT com
From:	Jani Tiainen <redetin AT luukku DOT com>
Subject:	Re: gcc 3.3.3, const symbols and shared libraries
Date:	Tue, 29 Mar 2005 18:10:03 +0300
Lines:	66
Message-ID:	<d2br2h$vdf$1@sea.gmane.org>
References:	<4246D5A0 DOT 4070409 AT huarp DOT harvard DOT edu> <42491C9C DOT 5000906 AT familiehaase DOT de> <42495B9B DOT 7090900 AT huarp DOT harvard DOT edu>
Mime-Version:	1.0
X-Complaints-To:	usenet AT sea DOT gmane DOT org
X-Gmane-NNTP-Posting-Host:	kotivayla-138-232.tikkacom.fi
User-Agent:	Mozilla Thunderbird 0.9 (Windows/20041118)
In-Reply-To:	<42495B9B.7090900@huarp.harvard.edu>
X-IsSubscribed:	yes

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/

- Raw text -