Re: gcc 3.3.3, const symbols and shared libraries
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;) I ask because I just spent two days trying to compile a number of libraries, and ran into problems at every turn due to this bug. Gerrit -- =^..^= Action Soccer: http://www.action-soccer.de/?lv=deid=505 (german online game) -- 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/
Re: gcc 3.3.3, const symbols and shared libraries
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. 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? -Norton begin:vcard fn:Norton Allen n:Allen;Norton org:Harvard University;Anderson Group, DEAS/CCB adr;dom:;;12 Oxford St.;Cambridge;MA;02138 email;internet:[EMAIL PROTECTED] title:Software Engineer tel;work:617-495-5922 x-mozilla-html:FALSE url:http://www.arp.harvard.edu/ version:2.1 end:vcard -- 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/
Re: gcc 3.3.3, const symbols and shared libraries
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/
Re: gcc 3.3.3, const symbols and shared libraries
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. 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? -Norton I needed to apply these changes too (I'm the maintainer of glib2), I think it is required for those platforms coming with gcc in question as default compiler, yes. However, only parts where libpopt is involved where affected, the usual way oppt was used doesn't work, at least with Cygwin. Gerrit -- =^..^= Action Soccer: http://www.action-soccer.de/?lv=deid=505 (german online game) -- 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/
