--- Begin Message ---
Package: libc6
Version: 2.17-1
Severity: serious
Justification: ABI breakage
__secure_getenv is being used by util-linux in libblkid.a.
Any program linked against libblkid.a will have a dependency
upon this symbol. This includes e2fsprogs, which currently
FTBFSes. There may be additional users; this is just the
one I'm aware of.
The new glibc has secure_getenv to replace __secure_getenv
but the old symbol is not retained.
I've NMUed util-linux to force it to be rebuilt. This
should fix the immediate issues. But the wider question is
how widespread was usage of this symbol, and do we need to
rebuild everything or could the symbol be restored for
backward compatibility?
Regards,
Roger
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (550, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6 depends on:
ii debconf [debconf-2.0] 1.5.50
ii libgcc1 1:4.8.0-6
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii glibc-doc 2.17-1
ii locales 2.17-1
ii locales-all [locales] 2.17-1
-- debconf information excluded
--- End Message ---
--- Begin Message ---
On Sun, May 12, 2013 at 11:45:49PM +0200, Aurelien Jarno wrote:
> On Sun, May 12, 2013 at 09:16:19PM +0100, Roger Leigh wrote:
> > Package: libc6
> > Version: 2.17-1
> > Severity: serious
> > Justification: ABI breakage
> >
> > __secure_getenv is being used by util-linux in libblkid.a.
> > Any program linked against libblkid.a will have a dependency
> > upon this symbol. This includes e2fsprogs, which currently
> > FTBFSes. There may be additional users; this is just the
> > one I'm aware of.
>
> This was an internal function, that should not have been used. Given it
> has been used anyway, it has been decided to provide the secure_getenv
> function instead.
>
> > The new glibc has secure_getenv to replace __secure_getenv
> > but the old symbol is not retained.
>
> This is not true. __secure_getenv is still available and will be
> available forever (well as long as the soname doesn't change), it's
> just not possible to link against it:
>
> 856: 0000000000039a90 27 FUNC WEAK DEFAULT 12 __secure_getenv@GLIBC_2.2.5
> 1715: 0000000000039a90 27 FUNC WEAK DEFAULT 12 secure_getenv@@GLIBC_2.17
>
> In short it's an API breakage, but not an ABI breakage.
>
> > I've NMUed util-linux to force it to be rebuilt. This
> > should fix the immediate issues. But the wider question is
> > how widespread was usage of this symbol, and do we need to
> > rebuild everything or could the symbol be restored for
> > backward compatibility?
>
> We should rebuild packages using it, but they are still functional until
> they are rebuilt.
>
> With all these explanations given, I think this bug can be closed, or at
> least the severity decrease, as the "Justification: ABI breakage" is not
> correct.
OK, thanks for the detailed explanation. So long as it's not breaking
the ABI, that's good. I'll have a look at the reverse build-deps of
libblkid and see what needs fixing.
Thanks again,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--- End Message ---