Re: Accepted eglibc 2.11.3-4+deb6u10 (source all amd64) into squeeze-lts

[Brian May <bam@debian.org>]

Matus UHLAR - fantomas <uhlar@fantomas.sk> writes:

> yes, there was:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814078

Is the BTS the appropriate place for these bugs? I don't think they come
to the LTS team who need to see them.


>From that bug report:

"Indeed, it looks like the fix has been wrongly backported. The new
symbols are supposed to be private symbols (versioned with
GLIBC_PRIVATE). Otherwise the ABI is changed and this can cause
compatibility issues with other version of the libc on wheezy, jessie,
etc. or other distributions."

Oops.

I can see what happened, the upstream diff has:

--- a/stdlib/Versions
+++ b/stdlib/Versions
@@ -118,5 +118,6 @@ libc {
     # Used from other libraries
     __libc_secure_getenv;
     __call_tls_dtors;
+    __strtof_nan; __strtod_nan; __strtold_nan;
   }
 }


The patch, to the squeeze version has:

Index: eglibc-2.11.3/stdlib/Versions
===================================================================
--- eglibc-2.11.3.orig/stdlib/Versions
+++ eglibc-2.11.3/stdlib/Versions
@@ -8,6 +8,7 @@ libc {
·
     # functions used in other libraries
     __secure_getenv;
+    __strtof_nan; __strtod_nan; __strtold_nan;
·
     # a*
     a64l; abort; abs; atexit; atof; atoi; atol; atoll;


Look the same???

No, because in upstream __secure_getenv is part of GLIBC_PRIVATE, in
squeeze __secure_getenv was part of GLIBC_2.0 - So we end up putting the
code in a different spot. You can't tell this for certain just by
looking at the patch (although the references to the public symbols
should be a hint).

I am guessing this is because they were more conservative with what they
use GLIBC_PRIVATE for back in the time of squeeze.

Question is: Is it worth fixing this? As it is extra symbols, I don't
think it can cause any breakage other then with already running
processes. Especially as squeeze-lts support will be ending soon.
-- 
Brian May <bam@debian.org>