On 01/09/19 12:47 +0200, Rainer Orth wrote:
And now the Solaris libstdc++ baseline updates for the gcc-9 branch.
Tested on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01]. Ok for
mainline?
OK for gcc-9-branch :-)
Thanks.
On 01/09/19 12:45 +0200, Rainer Orth wrote:
Here's are the updates to the Solaris libstdc++ baselines on mainline.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. Ok for mainline?
Yes, thanks.
And now the Solaris libstdc++ baseline updates for the gcc-9 branch.
Tested on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01]. Ok for
mainline?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld
Here's are the updates to the Solaris libstdc++ baselines on mainline.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. Ok for mainline?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld Univ
Hi Jakub,
> On Fri, Apr 26, 2019 at 12:11:55PM +0100, Jonathan Wakely wrote:
>> On 26/04/19 09:58 +0200, Rainer Orth wrote:
>> > It recently occured to me that almost none of the libstdc++ abi
>> > baselines have been updated for the GCC 9 release. The following patch
>> > corrects this for Solar
On Fri, Apr 26, 2019 at 12:11:55PM +0100, Jonathan Wakely wrote:
> On 26/04/19 09:58 +0200, Rainer Orth wrote:
> > It recently occured to me that almost none of the libstdc++ abi
> > baselines have been updated for the GCC 9 release. The following patch
> > corrects this for Solaris. The baseline
On 26/04/19 09:58 +0200, Rainer Orth wrote:
It recently occured to me that almost none of the libstdc++ abi
baselines have been updated for the GCC 9 release. The following patch
corrects this for Solaris. The baselines were generated on the affected
releases with make new-abi-baseline. Given
It recently occured to me that almost none of the libstdc++ abi
baselines have been updated for the GCC 9 release. The following patch
corrects this for Solaris. The baselines were generated on the affected
releases with make new-abi-baseline. Given that they only contain
additions for versions
On 08/04/15 15:41 +0200, Rainer Orth wrote:
With the GCC 5 release approaching, it's time to update the Solaris
baselines again.
This patch does just that and is pretty much straightforward:
* With one exception, all new symbols are in the GLIBCXX_3.4.21 and
CXXABI_1.3.9 versions.
* On Solari
With the GCC 5 release approaching, it's time to update the Solaris
baselines again.
This patch does just that and is pretty much straightforward:
* With one exception, all new symbols are in the GLIBCXX_3.4.21 and
CXXABI_1.3.9 versions.
* On Solaris/x86 only (obviously), we have
+OBJECT:0:CX
On 6 January 2014 14:10, Rainer Orth wrote:
> Since the GCC 4.9.0 release is approaching, we should update the Solaris
> baselines again.
>
> This patch does just that, bootstrapped without regressions on the full
> rang of Solaris configurations ({i386,sparc}-*-solaris2.{9,10,11}).
>
> Ok for main
Since the GCC 4.9.0 release is approaching, we should update the Solaris
baselines again.
This patch does just that, bootstrapped without regressions on the full
rang of Solaris configurations ({i386,sparc}-*-solaris2.{9,10,11}).
Ok for mainline now or better wait until a bit closer to the releas
On 28 February 2013 13:28, Rainer Orth wrote:
> Hi Paolo,
>
>> On 02/26/2013 12:33 PM, Rainer Orth wrote:
>>> Ok for mainline?
>> I suppose you don't need an approval for the Solaris-specific files, like
>> such baselines.
>
> probably not, but it's certainly good to have the changes sanity-checked
Hi Paolo,
> On 02/26/2013 12:33 PM, Rainer Orth wrote:
>> Ok for mainline?
> I suppose you don't need an approval for the Solaris-specific files, like
> such baselines.
probably not, but it's certainly good to have the changes sanity-checked
by someone with knowledge of the libstdc++ ABI, even if
Hi,
On 02/26/2013 12:33 PM, Rainer Orth wrote:
Ok for mainline?
I suppose you don't need an approval for the Solaris-specific files,
like such baselines.
Paolo.
With gcc 4.8 getting closer to release, it seems the right time to
update the libstdc++ baselines for Solaris again, assuming that no
further symbols will be added before then.
Apart from the new versions (CXXABI_1.3.7, GLIBCXX_3.4.18), the
following symbols get added:
solaris2.9:
FUNC:std::bad_
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
47 matches
Mail list logo
