Libstdc++ versioning issues

Libstdc++ versioning issues

[Mark Mitchell]

Benjamin --

Right now, the libstdc++ versioning/ABI situation is is all that stands 
between us and 4.0.1 RC2, now that Jakub has fixed the GLIBC miscompilation.

What is an ETA for additional information?  Am I correct in 
understanding, from your previous mail, that these problems occurred in 
4.0.0 as well?

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Libstdc++ versioning issues

[Benjamin Kosnik]

> What is an ETA for additional information?  Am I correct in 
> understanding, from your previous mail, that these problems occurred in 
> 4.0.0 as well?

Hi Mark. Thanks for your patience.

I'm testing a patch that resolves the issue. I expect to have
additional details within 24 hrs, and will let you know details.

-benjamin

Re: Libstdc++ versioning issues

[Mike Hearn]

On Tue, 14 Jun 2005 20:24:40 -0500, Benjamin Kosnik wrote:
> I'm testing a patch that resolves the issue. I expect to have additional
> details within 24 hrs, and will let you know details.

Is this bug #21405, or some other versioning issue?

thanks -mike

Re: Libstdc++ versioning issues

[Paolo Carlini]

Mike Hearn wrote:

>On Tue, 14 Jun 2005 20:24:40 -0500, Benjamin Kosnik wrote:
>  
>
>>I'm testing a patch that resolves the issue. I expect to have additional
>>details within 24 hrs, and will let you know details.
>>    
>>
>Is this bug #21405, or some other versioning issue?
>  
>
The issue that Benjamin just fixed is very simple to explain (much less
to fix ;) : some recently added exported symbols had the default v6
version, that is, 3.4.0, instead of 3.4.5.

Paolo.

Re: Libstdc++ versioning issues

[Mike Hearn]

On Sun, 19 Jun 2005 15:06:58 +0200, Paolo Carlini wrote:
> The issue that Benjamin just fixed is very simple to explain (much less
> to fix ;) : some recently added exported symbols had the default v6
> version, that is, 3.4.0, instead of 3.4.5.

Ah I see :) 

Are the new symbols new APIs, or will pre-existing code compiled with GCC
3.4.5 depend on these symbols when they would not have done when compiled
with GCC 3.4.0?

Also, is anybody looking at bug #21405? This bug makes the symbol
versioning not so useful - to successfully distribute C++ apps on Linux we
have had to resort to a binary diffing/cross-build system so the user gets
a binary built with the right ABI installed. This problem affects games a
lot, because they tend to use SDL and libSDL dlopens sound drivers
according to the environment. When SDL dlopens the aRTS driver, you get
both libstdc++.so.5 and libstdc++.so.6 versions mixed into the same binary
and the symbol versioning is not enough to stop them conflicting.

thanks -mike

Re: Libstdc++ versioning issues

[Paolo Carlini]

Mike Hearn wrote:

>Are the new symbols new APIs, or will pre-existing code compiled with GCC
>3.4.5 depend on these symbols when they would not have done when compiled
>with GCC 3.4.0?
>  
>
AFAICS, there are no problems whatsover, because version 3.4.5 is *new*
in 4.0.1.

Paolo.

po file update

[Jakub Jelinek]

On Tue, Jun 14, 2005 at 04:43:47PM -0700, Mark Mitchell wrote:
> Right now, the libstdc++ versioning/ABI situation is is all that stands 
> between us and 4.0.1 RC2, now that Jakub has fixed the GLIBC miscompilation.

Weren't we waiting for the updated po files (at least for the translations
that were known to contain bugs that resulted in compiler crashes,
i.e. de, es, tr and zh_CN)?

Joseph, have you uploaded 4.0.1 RC to the TP robot?
Will it msgmerge automatically and send back or do we need to wait for
the translators to actually msgmerge it manually?

	Jakub

Re: po file update

[Joseph S. Myers]

On Wed, 15 Jun 2005, Jakub Jelinek wrote:

> On Tue, Jun 14, 2005 at 04:43:47PM -0700, Mark Mitchell wrote:
> > Right now, the libstdc++ versioning/ABI situation is is all that stands 
> > between us and 4.0.1 RC2, now that Jakub has fixed the GLIBC miscompilation.
> 
> Weren't we waiting for the updated po files (at least for the translations
> that were known to contain bugs that resulted in compiler crashes,
> i.e. de, es, tr and zh_CN)?
> 
> Joseph, have you uploaded 4.0.1 RC to the TP robot?
> Will it msgmerge automatically and send back or do we need to wait for
> the translators to actually msgmerge it manually?

I submitted it to the TP a week ago.  When it has been processed, the 
automerged files with the problem translations marked fuzzy by msgmerge 
0.14.5 will appear on the TP site (the automerged files don't get mailed 
out) - after new .pot files have been processed by the TP, I download the 
new merged .po files and commit them.  However, the TP site still shows 
the 4.0.0 .pot files and translations only.

Perhaps there is some problem with the updating of the TP site?  The pages 
I refer to to see if the new .pot files have been processed are

http://www.iro.umontreal.ca/translation/registry.cgi?domain=gcc
http://www.iro.umontreal.ca/translation/registry.cgi?domain=cpplib

but the table on the latter page is out of date with regard to how many 
Swedish message translations there are for cpplib (an updated complete 
translation was recently sent by the TP robot to gcc-patches).  However, 
trying with wget shows that the 4.0.1-b20050607.po files are not there - 
it isn't just a matter of there being no links to them.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: po file update

[Mark Mitchell]

Joseph S. Myers wrote:
> On Wed, 15 Jun 2005, Jakub Jelinek wrote:
> 
> 
>>On Tue, Jun 14, 2005 at 04:43:47PM -0700, Mark Mitchell wrote:
>>
>>>Right now, the libstdc++ versioning/ABI situation is is all that stands 
>>>between us and 4.0.1 RC2, now that Jakub has fixed the GLIBC miscompilation.
>>
>>Weren't we waiting for the updated po files (at least for the translations
>>that were known to contain bugs that resulted in compiler crashes,
>>i.e. de, es, tr and zh_CN)?
>>
>>Joseph, have you uploaded 4.0.1 RC to the TP robot?
>>Will it msgmerge automatically and send back or do we need to wait for
>>the translators to actually msgmerge it manually?
> 
> 
> I submitted it to the TP a week ago. 

I'm not willing to hold things up indefinitely on this issue.  Once the 
V3 situation is resolved, I plan to make RC2.  If the translations are 
available before the final release, we'll include them; otherwise, we won't.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: po file update

["Martin v. Löwis"]

Joseph S. Myers wrote:
> I submitted it to the TP a week ago.

Sorry it took so long. Karl is on vacation, and I was busy with other
stuff. Please verify whether the merge indeed had the desired effect.

> Perhaps there is some problem with the updating of the TP site?  

Also that. DIRO (UMontreal) shut down the machines that ran our
cron jobs, and hasn't told us what machine to use instead. I currently
run them manually from time to time.

Regards,
Martin

Re: Libstdc++ versioning issues

[John David Anglin]

> AFAICS, there are no problems whatsover, because version 3.4.5 is *new*
> in 4.0.1.

See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22109>.  This is
also <http://sources.redhat.com/bugzilla/show_bug.cgi?id=1022>.

This is probably a bug in binutils but I don't have a warm fuzzy
feeling about this.  I have done some debugging of the problem.
It appears that PLABEL relocations aren't being correctly handled
for versioned symbols.  However, it's not clear why we have a PLABEL
relocation for the symbol _ZNSt11char_traitsIcE2eqERKcS2_@@GLIBCXX_3.4.5
in the first place.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Libstdc++ versioning issues

[Paolo Carlini]

John David Anglin wrote:

>>AFAICS, there are no problems whatsover, because version 3.4.5 is *new*
>>in 4.0.1.
>>    
>>
>See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22109>.  This is
>also <http://sources.redhat.com/bugzilla/show_bug.cgi?id=1022>.
>
>This is probably a bug in binutils but I don't have a warm fuzzy
>feeling about this.  I have done some debugging of the problem.
>It appears that PLABEL relocations aren't being correctly handled
>for versioned symbols.  However, it's not clear why we have a PLABEL
>relocation for the symbol _ZNSt11char_traitsIcE2eqERKcS2_@@GLIBCXX_3.4.5
>in the first place.
>  
>
I have nothing technically interesting to say about these specific
issues and, in any case, people like Jakub and Benjamin are much more
expert than me in this area.

However, please don't point out these issues citing my sentence of
earlier today. That's misleading: I was only replying to Mike Hearn's
concerns about incompatibilities between different versions of the
library and certainly Mike was not interested in binutils issues and
possible linker bugs.

Paolo.