glibc 2.15

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

glibc 2.15

Ulrich Drepper-2
I checked in the changes I intend to have in 2.15.  I will tag the
three for the release on Sunday or Monday unless something comes up.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

cryptooctoploid (Bugzilla)
Ulrich Drepper <drepper <at> gmail.com> writes:
> > I checked in the changes I intend to have in 2.15.  I will tag the
> three for the release on Sunday or Monday unless something comes up.

Bug 12871 still crashes various programs on my machine.
There's a patch available to fix the issue since June.
Why wasn't it applied yet?


Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Jeff Law
In reply to this post by Ulrich Drepper-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/23/11 22:17, Ulrich Drepper wrote:
> I checked in the changes I intend to have in 2.15.  I will tag the
> three for the release on Sunday or Monday unless something comes
> up.
An FYI, this patch:


commit c5a0802a682dba23f92d47f0f99775aebfbe2539
Author: Andreas Schwab <[hidden email]>
Date:   Mon Nov 28 13:38:19 2011 +0100

    Handle EAGAIN from FUTEX_WAIT_REQUEUE_PI


Has been reported as causing numerous problems in Fedora & Debian.  I
don't think anyone has done any serious analysis of the issue, but the
patch has been pulled from both distributions because of the
instability it's introduced.

https://bugzilla.redhat.com/show_bug.cgi?id=769421
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651899

It might be worth your time to dig further into the change or pull it
from 2.15 pending a deeper investigation.

Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEbBAEBAgAGBQJPATa6AAoJEBRtltQi2kC7iSgH9304jqLsbXwd+06eROk2ucq2
2QkePloGCecWudJylZ2gNuPEgMTP8/+lOI6p32NvxEU633rRMpIYtRflO+Xj7j6l
rMdeORu3A/hgcx/xDAbXm7xzgkk/2q8kAaHFzQqDDK6zephd6jwHAxw7as6rxwdG
qulW5sl7e/0IYDWylRnM7Ruo++6eVfRtwodeppDnYfkuiEyxUM7GK4W/zs+pCKkI
bRF7vlmsERncIiRyH8VXdGfzzTJt4Z/FP9tZBAuFNTiKVhuVVYn454bLuZcJEc2h
vOX3G5YQN1GrvgzYEVhlV+ZuEOowgAWAXY9FUrCsfRrzaAbzYMAco4LT3ywEjQ==
=q5fP
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Andreas Jaeger-8
In reply to this post by Ulrich Drepper-2
I just noticed that make check-abi fails for libm,

Andreas

--- -   2012-01-03 20:00:52.469311069 +0000
+++ /home/abuild/rpmbuild/BUILD/glibc-2.15/cc-base/math/libm.symlist
2012-01-03 20:00:52.460100038 +0000
@@ -315,0 +316,83 @@ GLIBC_2.1
+GLIBC_2.15
+ GLIBC_2.15 A
+ __acos_finite F
+ __acosf_finite F
+ __acosh_finite F
+ __acoshf_finite F
+ __acoshl_finite F
+ __acosl_finite F
+ __asin_finite F
+ __asinf_finite F
+ __asinl_finite F
+ __atan2_finite F
+ __atan2f_finite F
+ __atan2l_finite F
+ __atanh_finite F
+ __atanhf_finite F
+ __atanhl_finite F
+ __cosh_finite F
+ __coshf_finite F
...
+ __y1l_finite F
+ __yn_finite F
+ __ynf_finite F
+ __ynl_finite F
@@ -329,0 +413,2 @@ GLIBC_2.2
+GLIBC_2.4
+ GLIBC_2.4 A

--
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Roland McGrath-4
> I just noticed that make check-abi fails for libm,

There is probably a fair bit of bit-rot in check-abi.
We should decide whether we really want to support it or not.
Ideally, there would be some general tools for that sort of
thing that could be used by anybody wanting to keep their ABI
compatibility solid.  But since no such tools yet exist in the
GNU arsenal, perhaps check-abi is still better than nothing.
But it's not worth much if nobody uses it or keeps it up to date.

This particular question aside, I'm inclined to suggest we move to a policy
of filing bugzilla reports for anything that a hacker notices but is not
immediately fixing.


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Joseph Myers
On Tue, 3 Jan 2012, Roland McGrath wrote:

> > I just noticed that make check-abi fails for libm,
>
> There is probably a fair bit of bit-rot in check-abi.

Yes - the lists don't appear to have been updated since 2.3 in 2004.  
Regarding the other obsoletion discussions, all the non-TLS cases in the
lists could certainly be removed, and there ought to be a solution for
keeping lists for ports in sysdeps directories (as-is, the m68k data is
still in abilist/ in libc).  It's certainly much closer to being useful
than the other things discussed for removal, however - but it works best
when each configuration has someone who will update the ABI for that
architecture shortly before each major release is tagged.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Jeff Law
In reply to this post by Roland McGrath-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/03/12 13:54, Roland McGrath wrote:

>> I just noticed that make check-abi fails for libm,
>
> There is probably a fair bit of bit-rot in check-abi. We should
> decide whether we really want to support it or not. Ideally, there
> would be some general tools for that sort of thing that could be
> used by anybody wanting to keep their ABI compatibility solid.  But
> since no such tools yet exist in the GNU arsenal, perhaps check-abi
> is still better than nothing. But it's not worth much if nobody
> uses it or keeps it up to date.
>
> This particular question aside, I'm inclined to suggest we move to
> a policy of filing bugzilla reports for anything that a hacker
> notices but is not immediately fixing.
Interestingly enough this was passed along to me recently:

http://forge.ispras.ru/projects/abi-compliance-checker

Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPA3O/AAoJEBRtltQi2kC7jtEH/0j9hoLeGIRxTZWKj5VSk1n0
4LDrA1mr3CcSS4yekhF3Q9joP4mrNDviH9/d/HuQcwKUjz6CC2Cq9GOJ4sPJp3Jq
5zRvTJzQd8HEPEflTMEcrZQqxXUDjfuziyPjKPLpukgyCpOr49oliVq7eE920hXX
/tUWWV/fVSI0E476zrqz3rvGmP3CN+H/LYzAXdK7pibvhBMmTon5Ds46VqeB+Ydl
8UPkRM0IwWZOlNgrjh+HKAJvyx67mnZVmBLNzNIkxrD3462jv/846v1YcyisyWRW
z7fs7ya4MnFOiHw93Z9lFQIOJRkmmMlxS6sYQJPLmE/brvVJ14V32TsB+gMOcv4=
=nwq0
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Roland McGrath-4
In reply to this post by Joseph Myers
> Yes - the lists don't appear to have been updated since 2.3 in 2004.  
> Regarding the other obsoletion discussions, all the non-TLS cases in the
> lists could certainly be removed, and there ought to be a solution for
> keeping lists for ports in sysdeps directories (as-is, the m68k data is
> still in abilist/ in libc).  

Agreed.  The original intent was geared at not having too much duplication
in the same source tree, hence the goop that merges commonalities together.
But some slightly large text files in a repository and/or source tarball
really don't seem like such a big deal any more.  And IMHO certainly those
concerns are trumped by the proper segregation into add-on directories.

I can't tell any more whether we still intend for the ports repository to
be able to produce individual add-on tarballs instead of just the one big
glibc-ports tarball.  If we don't care about that any more, then having a
single abilist set in ports that does the deduplicating merge of all the
ones for configurations maintained in that repo would make sense.  (More on
that is a subject for libc-ports rather than here.)  But I think I'd really
be fine with abilist files living in sysdeps/ instead now.

The text file bloat aside, one nice feature of the deduplicating merge was
that you could really easily notice the divergence between configurations
by eyeball.  It's good to avoid gratuitous differences going in
inadvertently.  But that's eminently doable just with scriptery to do
comparisons as well.  It doesn't particularly require that the repository
contain merged files.  The most important thing is that people actually
look at both the version-to-version changes and the inter-configuration
divergence and make sure it's all what we want and not what we don't want.
Of course, it's no help unless that happens well before a release, when
we still have the chance to fix things.

> It's certainly much closer to being useful
> than the other things discussed for removal, however - but it works best
> when each configuration has someone who will update the ABI for that
> architecture shortly before each major release is tagged.

Yes, that's how it was when I originally added it.  But it's fallen off.
We should make it part of the official responsibilities of port maintainers
and release branch maintainers.

For that to really work, we'd need to start naming the maintainer for each
release branch before we actually make that release.  That would be a
better way to operate in numerous ways, but it hasn't happened yet.
I hope we can get more coherent about our procedures before 2.16.


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Roland McGrath-4
In reply to this post by Jeff Law
> Interestingly enough this was passed along to me recently:
>
> http://forge.ispras.ru/projects/abi-compliance-checker

Thanks for the pointer!  I hope someone here will take the time to look
into that and see whether it's worth using and is appropriate for something
that a GNU project's procedures should rely on and for integrating with
our procedures for libc.


Thanks,
Roland

Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Andreas Jaeger-8
In reply to this post by Roland McGrath-4
On 01/03/2012 09:54 PM, Roland McGrath wrote:
>[...]
> This particular question aside, I'm inclined to suggest we move to a policy
> of filing bugzilla reports for anything that a hacker notices but is not
> immediately fixing.

Will do now,
Andreas
--
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Carlos O'Donell-2
In reply to this post by cryptooctoploid (Bugzilla)
On Sat, Dec 24, 2011 at 4:06 AM, octoploid <[hidden email]> wrote:
> Ulrich Drepper <drepper <at> gmail.com> writes:
>> > I checked in the changes I intend to have in 2.15.  I will tag the
>> three for the release on Sunday or Monday unless something comes up.
>
> Bug 12871 still crashes various programs on my machine.
> There's a patch available to fix the issue since June.
> Why wasn't it applied yet?

Mark it with tag glibc_2.15 and I'll have a look at it.

Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Mike Frysinger
In reply to this post by Ulrich Drepper-2
On Friday 23 December 2011 17:17:15 Ulrich Drepper wrote:
> I checked in the changes I intend to have in 2.15.  I will tag the
> three for the release on Sunday or Monday unless something comes up.

i guess now starts the pleas for tarballs to get rolled + uploaded
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Roland McGrath-4
> i guess now starts the pleas for tarballs to get rolled + uploaded

We all appreciate Alfred's past assistance in doing this.  But I think it's
now time to declare this part of the release branch manager's responsibilities.
Which is to say, whine at Carlos.


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Carlos O'Donell-4
On 1/6/2012 4:50 PM, Roland McGrath wrote:
>> i guess now starts the pleas for tarballs to get rolled + uploaded
>
> We all appreciate Alfred's past assistance in doing this.  But I think it's
> now time to declare this part of the release branch manager's responsibilities.
> Which is to say, whine at Carlos.

I plan to look into it tomorrow, in addition to augmenting the wiki notes
where required.

Cheers,
Carlos.
--
Carlos O'Donell
Mentor Graphics / CodeSourcery
[hidden email]
+1 (613) 963 1026
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Alfred M. Szmidt
   >> i guess now starts the pleas for tarballs to get rolled + uploaded
   >
   > We all appreciate Alfred's past assistance in doing this.  But I think it's
   > now time to declare this part of the release branch manager's responsibilities.
   > Which is to say, whine at Carlos.

   I plan to look into it tomorrow, in addition to augmenting the wiki notes
   where required.

FWIW, if you need a hand then feel free to ask.
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Andrey Ponomarenko-3
In reply to this post by Roland McGrath-4
Hi,

On 01/04/2012 01:59 AM, Roland McGrath wrote:

>> Interestingly enough this was passed along to me recently:
>>
>> http://forge.ispras.ru/projects/abi-compliance-checker
> Thanks for the pointer!  I hope someone here will take the time to look
> into that and see whether it's worth using and is appropriate for something
> that a GNU project's procedures should rely on and for integrating with
> our procedures for libc.
>
>
> Thanks,
> Roland
>
>

Sample compatibility reports generated by abi-compliance-checker tool
for glibc release versions are available at this URL:
http://upstream-tracker.org/versions/glibc.html

The general use case for glibc is the following:

1. abi-compliance-checker -l glibc -dump 2.14.1.xml
     This command will create ABI dump for glibc 2.14.1
(glibc_2.14.1.abi.tar.gz).

2. abi-compliance-checker -l glibc -dump 2.15.xml
     This command will create ABI dump for glibc 2.15
(glibc_2.15.abi.tar.gz).

3. abi-compliance-checker -l glibc -d1 glibc_2.14.1.abi.tar.gz -d2
glibc_2.15.abi.tar.gz
     This command will compare two dumps and create binary compatibility
report between 2.14.1 and 2.15 versions (abi_compat_report.html).

2.14.1.xml and 2.15.xml are XML-descriptors (full template can be
generated by "-d" option of abi-compliance-checker):

     /* Primary Sections */

<version>
         2.14.1
</version>

<headers>
         /* path(s) to headers or directories with headers, one per line */
</headers>

<libs>
         /* path(s) to shared objects or directories with shared
objects, one per line */
</libs>

     /* Optional Sections */

<skip_headers>
         /* headers to skip, one per line */
</skip_headers>

<skip_libs>
         /* shared objects to skip, one per line */
</skip_libs>

         ...

--
Andrey Ponomarenko, ROSA Lab.

Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.15

Andreas Jaeger-8
In reply to this post by Jeff Law
Going through patches we apply for openSUSE, I noticed that we have this
patch in - and I don't think there's a solution for 2.16 yet.

Jeff, could you file a bugreport with details, please?

Is there anybody that could review this?

Andreas

On 01/02/2012 05:46 AM, Jeff Law wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/23/11 22:17, Ulrich Drepper wrote:
>> I checked in the changes I intend to have in 2.15.  I will tag the
>> three for the release on Sunday or Monday unless something comes
>> up.
> An FYI, this patch:
>
>
> commit c5a0802a682dba23f92d47f0f99775aebfbe2539
> Author: Andreas Schwab <[hidden email]>
> Date:   Mon Nov 28 13:38:19 2011 +0100
>
>      Handle EAGAIN from FUTEX_WAIT_REQUEUE_PI
>
>
> Has been reported as causing numerous problems in Fedora & Debian.  I
> don't think anyone has done any serious analysis of the issue, but the
> patch has been pulled from both distributions because of the
> instability it's introduced.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=769421
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651899
>
> It might be worth your time to dig further into the change or pull it
> from 2.15 pending a deeper investigation.
>
> Jeff
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEbBAEBAgAGBQJPATa6AAoJEBRtltQi2kC7iSgH9304jqLsbXwd+06eROk2ucq2
> 2QkePloGCecWudJylZ2gNuPEgMTP8/+lOI6p32NvxEU633rRMpIYtRflO+Xj7j6l
> rMdeORu3A/hgcx/xDAbXm7xzgkk/2q8kAaHFzQqDDK6zephd6jwHAxw7as6rxwdG
> qulW5sl7e/0IYDWylRnM7Ruo++6eVfRtwodeppDnYfkuiEyxUM7GK4W/zs+pCKkI
> bRF7vlmsERncIiRyH8VXdGfzzTJt4Z/FP9tZBAuFNTiKVhuVVYn454bLuZcJEc2h
> vOX3G5YQN1GrvgzYEVhlV+ZuEOowgAWAXY9FUrCsfRrzaAbzYMAco4LT3ywEjQ==
> =q5fP
> -----END PGP SIGNATURE-----
>


--
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126