Benjamin De Kosnik writes:
>> I was surprised to see GLIBCXX_3.4.15 symbols added, but then realized
>> you added the complete set so this seems fine.
>
> I meant to say: surprised to see GLIBCXX_3.4.16 symbols added, but then
> you the complete set so this seems fine. So the only added symbols
> I was surprised to see GLIBCXX_3.4.15 symbols added, but then realized
> you added the complete set so this seems fine.
I meant to say: surprised to see GLIBCXX_3.4.16 symbols added, but then
you the complete set so this seems fine. So the only added symbols are
the complete set of GLIBCXX_3.4
> After PRs libstdc++/52188 and libstdc++/52189 have been resolved, I'd
> finally like to update the Solaris baselines for the 4.7 release.
> This time, everything looks good: only additions to GLIBCXX_3.4.1[67],
> CXXABI_1.3.6, and CXXABI_TM_1, as expected.
>
> Bootstrapped without regressions o
After PRs libstdc++/52188 and libstdc++/52189 have been resolved, I'd
finally like to update the Solaris baselines for the 4.7 release. This
time, everything looks good: only additions to GLIBCXX_3.4.1[67],
CXXABI_1.3.6, and CXXABI_TM_1, as expected.
Bootstrapped without regressions on i386-pc-so
Paolo Carlini writes:
> I'm trying to understand why on Solaris you didn't see abi_check errors,
> because for sure on Linux those operators are in the baselines and normally
> exported, isn't just about the linker script. I repeat one last time: on
> Linux we started exporting the symbols @3.4.5
On 01/30/2012 07:25 PM, Rainer Orth wrote:
That's due to the way gld linker scripts work: every entry there just
works like sort of a wildcard: if the symbol is present in the input
objects, it is bound to the respective symbol, if it's missing, this
is silently ignored.
I know that.
I'm tryi
Paolo Carlini writes:
> On 01/30/2012 07:06 PM, Rainer Orth wrote:
>> A non-C++ change suddenly causing new C++ functions to be emitted that
>> are not present without that change would be a bug on Linux, too!
> I should have been more clear: it's *not* a versioning bug on Linux. Maybe
I never c
On 01/30/2012 07:06 PM, Rainer Orth wrote:
A non-C++ change suddenly causing new C++ functions to be emitted that
are not present without that change would be a bug on Linux, too!
I should have been more clear: it's *not* a versioning bug on Linux.
Maybe what is happening on Solaris is that thos
Paolo Carlini writes:
> On 01/30/2012 06:11 PM, Rainer Orth wrote:
>> I.e. there are *no* libstdc++ or C++ changes involved at all. IMO this is
>> a bug, plain and simple.
> Just to avoid all the pointless discussions we had last time: *on
> Solaris*. Because if you look at gnu.ver it's obvious t
On 01/30/2012 06:11 PM, Rainer Orth wrote:
I.e. there are *no* libstdc++ or C++ changes involved at all. IMO this
is a bug, plain and simple.
Just to avoid all the pointless discussions we had last time: *on
Solaris*. Because if you look at gnu.ver it's obvious that those symbols
*on Linux* wer
Rainer Orth writes:
> Paolo Carlini writes:
>
> +FUNC:_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5
> +FUNC:_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5
I don't think this is a new issue, I see it in 4.6 branch and even in 4.5
branch.
Jonathan Wakely writes:
> The change is probably pr 50196
>
> (Sent offlist because the android gmail app refuses to send plain text
> mails)
Right. I think about disabling _GLIBCXX_HAS_GTHREADS on Solaris 8 and 9
per default, with the option of enabling it knowing that it breaks
symbol version
Jakub Jelinek writes:
> On Mon, Jan 23, 2012 at 07:31:55PM +0100, Rainer Orth wrote:
>> * There's quite a number of additions to 3.4.11:
>
> Probably Solaris didn't have _GLIBCXX_HAS_GTHREADS support
> before and now does?
Right, it didn't on Solaris 8 and 9 in 4.6, but does now. It seems the
t
On Mon, Jan 23, 2012 at 07:31:55PM +0100, Rainer Orth wrote:
> * There's quite a number of additions to 3.4.11:
Probably Solaris didn't have _GLIBCXX_HAS_GTHREADS support
before and now does?
config/abi/pre/*.ver isn't currently conditionalized in any way,
so I don't see an easy way to move these
Jakub Jelinek writes:
>> I doubt that, otherwise the additions to versions already released
>> should have been flagged as such on Solaris, but abi_check suggests they
>> are benign.
>
> If you mean
> TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
>
Jakub Jelinek writes:
> On Fri, Jan 27, 2012 at 05:54:56PM +0100, Rainer Orth wrote:
>> Paolo Carlini writes:
>>
>> > On 01/27/2012 05:46 PM, Rainer Orth wrote:
>> >> I'd even argue that abi_check should flag all additions to released
>> >> versions as a hard error.
>> > Again, agreed. As a mat
On 01/27/2012 05:53 PM, Rainer Orth wrote:
Paolo Carlini writes:
On 01/27/2012 05:46 PM, Rainer Orth wrote:
... even on x86_64-unknown-linux-gnu (CentOS 5.6), I see additions to
3.4.11 (at least beyond the current baselines).
Sure there are additions at 3.4.11, regularly explicitly exported
On Fri, Jan 27, 2012 at 05:54:56PM +0100, Rainer Orth wrote:
> Paolo Carlini writes:
>
> > On 01/27/2012 05:46 PM, Rainer Orth wrote:
> >> I'd even argue that abi_check should flag all additions to released
> >> versions as a hard error.
> > Again, agreed. As a matter of fact, I'm pretty sure we
Hi,
On Fri, 27 Jan 2012, Rainer Orth wrote:
> Paolo Carlini writes:
>
> > On 01/27/2012 05:27 PM, Rainer Orth wrote:
> >> They would be exported @3.4.11 if they had been present before. On
> >> Solaris before 4.7, there were not. Rainer
> > Ah, Ok, now I see, you are talking about *Solaris-spe
Paolo Carlini writes:
> On 01/27/2012 05:46 PM, Rainer Orth wrote:
>> I'd even argue that abi_check should flag all additions to released
>> versions as a hard error.
> Again, agreed. As a matter of fact, I'm pretty sure we do that already, I'm
> pretty sure Benjamin tightened abi_check in the li
Paolo Carlini writes:
> On 01/27/2012 05:46 PM, Rainer Orth wrote:
>> ... even on x86_64-unknown-linux-gnu (CentOS 5.6), I see additions to
>> 3.4.11 (at least beyond the current baselines).
> Sure there are additions at 3.4.11, regularly explicitly exported
> @3.4.11 in the linker script. Ever
On 01/27/2012 05:46 PM, Rainer Orth wrote:
I'd even argue that abi_check should flag all additions to released
versions as a hard error.
Again, agreed. As a matter of fact, I'm pretty sure we do that already,
I'm pretty sure Benjamin tightened abi_check in the light of that
problem we had in 20
On 01/27/2012 05:46 PM, Rainer Orth wrote:
... even on x86_64-unknown-linux-gnu (CentOS 5.6), I see additions to
3.4.11 (at least beyond the current baselines).
Sure there are additions at 3.4.11, regularly explicitly exported
@3.4.11 in the linker script. Everything went as planned, I repeat. T
Paolo Carlini writes:
> On 01/27/2012 05:27 PM, Rainer Orth wrote:
>> They would be exported @3.4.11 if they had been present before. On
>> Solaris before 4.7, there were not. Rainer
> Ah, Ok, now I see, you are talking about *Solaris-specific* issues. Because
Perhaps partially, but ...
> Linu
On 01/27/2012 05:22 PM, Paolo Carlini wrote:
Perhaps you have a pointer?
.
I can search, but really the issue is very, very old and we already
released *many* GCCs "affected".
This one:
2005-06-23 Jakub Jelinek
PR libstdc++/22109
* src/compatibility.cc (_GLIBCXX_SYMVER_COMPATIBILIT
On 01/27/2012 05:27 PM, Rainer Orth wrote:
They would be exported @3.4.11 if they had been present before. On
Solaris before 4.7, there were not. Rainer
Ah, Ok, now I see, you are talking about *Solaris-specific* issues.
Because Linux is fine (or that old small glitch with istreambuf_iterator
Paolo Carlini writes:
+FUNC:_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5
+FUNC:_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5
>>> I don't think this is a new issue, I see it in 4.6 branch and even in 4.5
>>> branch. At some point we had a proble
On 01/27/2012 05:18 PM, Rainer Orth wrote:
Paolo Carlini writes:
On 01/23/2012 07:31 PM, Rainer Orth wrote:
* I noticed several new symbols being placed into GLIBCXX_3.4.5, which
also happens with gld and thus isn't an issue with Sun ld versioning
support. Adding to an old version is
Paolo Carlini writes:
> On 01/23/2012 07:31 PM, Rainer Orth wrote:
>> * I noticed several new symbols being placed into GLIBCXX_3.4.5, which
>>also happens with gld and thus isn't an issue with Sun ld versioning
>>support. Adding to an old version is not supposed to happen and must
>>
On 01/23/2012 07:31 PM, Rainer Orth wrote:
* I noticed several new symbols being placed into GLIBCXX_3.4.5, which
also happens with gld and thus isn't an issue with Sun ld versioning
support. Adding to an old version is not supposed to happen and must
be fixed.
+FUNC:_ZNSt19istreambuf_
Rainer Orth writes:
> Just as for the GCC 4.6 release, I plan to update the Solaris baselines
> before 4.7.0 ships. The following untested patch (simply created with
> make new-abi-baseline) would do so, but I don't propose installing it
> yet for several reasons:
>
> * I'd like the baselines to
31 matches
Mail list logo
