Subject: libc6: Upgrade can make the linker unusable
Date: Wed, 16 Dec 2015 13:15:47 -0800
Package: libc6
Severity: normal
Hi. I had
libc6 = 2.19-22
binutils = 2.25-4
and all was well. Then I upgraded to libc6 = 2.21-4 (currently latest in
sid). As a result, even the most basic build-time linking would fail.
For instance, with a trivial hello-world program:
$ gcc-5 -o tst tst.c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
This would happen with gcc-5 and with gcc-4.9. Downgrading libc6 would
fix it. After some fiddling I realized that upgrading to binutils =
2.25.90.20151209-1 (currently latest in sid) fixes it. I.e. with the
latest libc6 and the latest binutils packages things work.
Can the broken combination be prevented with some Conflicts: tags?
Currently this is a trap for the unwary.
Acknowledgement sent
to Aurelien Jarno <[email protected]>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <[email protected]>.
(Wed, 16 Dec 2015 22:39:03 GMT) (full text, mbox, link).
Subject: Re: Bug#808181: libc6: Upgrade can make the linker unusable
Date: Wed, 16 Dec 2015 23:36:51 +0100
On 2015-12-16 13:15, Dima Kogan wrote:
> Package: libc6
> Severity: normal
>
> Hi. I had
>
> libc6 = 2.19-22
> binutils = 2.25-4
>
> and all was well. Then I upgraded to libc6 = 2.21-4 (currently latest in
> sid). As a result, even the most basic build-time linking would fail.
> For instance, with a trivial hello-world program:
>
> $ gcc-5 -o tst tst.c
>
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init'
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
>
> This would happen with gcc-5 and with gcc-4.9. Downgrading libc6 would
> fix it. After some fiddling I realized that upgrading to binutils =
> 2.25.90.20151209-1 (currently latest in sid) fixes it. I.e. with the
> latest libc6 and the latest binutils packages things work.
The problem is not introduced by the glibc, but just by the fact that
it has been built with a recent binutils version which adds new
relocation types on i386 and amd64. This means that ALL static libraries
are affected by this problem.
> Can the broken combination be prevented with some Conflicts: tags?
> Currently this is a trap for the unwary.
I therefore don't think we need to fix that at the glibc level. Either
we just ignore the problem saying we don't support partial upgrades or
we try to find a global way to fix the dependencies for all libraries.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
[email protected]http://www.aurel32.net
Acknowledgement sent
to Christophe <[email protected]>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <[email protected]>.
(Thu, 17 Dec 2015 08:27:04 GMT) (full text, mbox, link).
I am not sure to understand correctly...
I currently have the same behavior with Stretch without sid/experimental
repository, and I see binutils is not ready to migrate from testing, so no
partial updates here I think.
I do not understand how libc6-dev came built with an unavailable binutils
version on Stretch.
Christophe
Acknowledgement sent
to Emmanuel Charpentier <[email protected]>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <[email protected]>.
(Thu, 17 Dec 2015 08:42:04 GMT) (full text, mbox, link).
Subject: libc6: Upgrade can make the linker unusable
Date: Thu, 17 Dec 2015 09:39:26 +0100
Dear developers,
I've just got bitten by this bug. About 3 millimeters from my carotid
artery...
This bugs effectively renders my system unusable for compilation
purposes : even extremely mundane uses, such as upgradng some R
packages, is now impossible.
Suggestions :
1) The gravity of this bug should be elevated : it renders the system
unusable at least for some mundane uses.
2) The upgrade to glibc should be conditioned to the upgrade of
binutils
3) A workaround should be posted on this bug report as soon as possible
(upgrade to unstable's binutils ?), and possibly publicized by larger
means (finding this bug is not obvious for pedestrian users like
me...).
Sincerely yours,
--
Emmanuel Charpentier
Acknowledgement sent
to Vlad Orlov <[email protected]>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <[email protected]>.
(Thu, 17 Dec 2015 09:36:04 GMT) (full text, mbox, link).
Subject: Re: Bug#808181: libc6: Upgrade can make the linker unusable
Date: Thu, 17 Dec 2015 12:29:54 +0300
Control: severity -1 important
Control: tags -1 stretch
Hi,
Just stumbled upon this today in Testing (Stretch) - after today's libc6 upgrade.
This issue breaks compilation of ANY autotools-based project as ld fails early in the configure phase:
configure:3441: checking whether the C compiler works
configure:3463: gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c >&5
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
The system has been updated with the usual dist-upgrade, so I don't understand the mentioning
of some partial upgrades above (and completely don't understand the part about "ignore the problem").
Acknowledgement sent
to Aurelien Jarno <[email protected]>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <[email protected]>.
(Thu, 17 Dec 2015 10:15:04 GMT) (full text, mbox, link).
Subject: Re: Bug#808181: libc6: Upgrade can make the linker unusable
Date: Thu, 17 Dec 2015 11:10:43 +0100
reassign 808181 libc6-dev
reassign 808205 libc6-dev
forcemerge 808181 808205
forcemerge 808181 808206
severity 808181 serious
thanks
On 2015-12-16 23:36, Aurelien Jarno wrote:
> On 2015-12-16 13:15, Dima Kogan wrote:
> > Package: libc6
> > Severity: normal
> >
> > Hi. I had
> >
> > libc6 = 2.19-22
> > binutils = 2.25-4
> >
> > and all was well. Then I upgraded to libc6 = 2.21-4 (currently latest in
> > sid). As a result, even the most basic build-time linking would fail.
> > For instance, with a trivial hello-world program:
> >
> > $ gcc-5 -o tst tst.c
> >
> > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init'
> > /usr/bin/ld: final link failed: Bad value
> > collect2: error: ld returned 1 exit status
> >
> > This would happen with gcc-5 and with gcc-4.9. Downgrading libc6 would
> > fix it. After some fiddling I realized that upgrading to binutils =
> > 2.25.90.20151209-1 (currently latest in sid) fixes it. I.e. with the
> > latest libc6 and the latest binutils packages things work.
>
> The problem is not introduced by the glibc, but just by the fact that
> it has been built with a recent binutils version which adds new
> relocation types on i386 and amd64. This means that ALL static libraries
> are affected by this problem.
>
> > Can the broken combination be prevented with some Conflicts: tags?
> > Currently this is a trap for the unwary.
>
> I therefore don't think we need to fix that at the glibc level. Either
> we just ignore the problem saying we don't support partial upgrades or
> we try to find a global way to fix the dependencies for all libraries.
We are working to migrate binutils version 2.25.90.20151209-1 into
testing asap. If everything goes well it should be the case after the
13:52 UTC dinstall run, so a few hours after that on the mirrors.
In the meantime fetching and installing this version from sid, should
solve the issue.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
[email protected]http://www.aurel32.net
Acknowledgement sent
to Vlad Orlov <[email protected]>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <[email protected]>.
(Thu, 17 Dec 2015 10:45:12 GMT) (full text, mbox, link).
Subject: Re[2]: Bug#808181: libc6: Upgrade can make the linker unusable
Date: Thu, 17 Dec 2015 13:36:09 +0300
Hi,
> We are working to migrate binutils version 2.25.90.20151209-1 into
> testing asap. If everything goes well it should be the case after the
> 13:52 UTC dinstall run, so a few hours after that on the mirrors.
>
> In the meantime fetching and installing this version from sid, should
> solve the issue.
Thanks, that version solved the issue indeed. Compilation goes fine now.
Reply sent
to Aurelien Jarno <[email protected]>:
You have taken responsibility.
(Fri, 18 Dec 2015 13:49:01 GMT) (full text, mbox, link).
Notification sent
to Dima Kogan <[email protected]>:
Bug acknowledged by developer.
(Fri, 18 Dec 2015 13:49:01 GMT) (full text, mbox, link).
Subject: Re: Bug#808181: libc6: Upgrade can make the linker unusable
Date: Fri, 18 Dec 2015 14:46:18 +0100
On 2015-12-17 11:10, Aurelien Jarno wrote:
> reassign 808181 libc6-dev
> reassign 808205 libc6-dev
> forcemerge 808181 808205
> forcemerge 808181 808206
> severity 808181 serious
> thanks
>
> On 2015-12-16 23:36, Aurelien Jarno wrote:
> > On 2015-12-16 13:15, Dima Kogan wrote:
> > > Package: libc6
> > > Severity: normal
> > >
> > > Hi. I had
> > >
> > > libc6 = 2.19-22
> > > binutils = 2.25-4
> > >
> > > and all was well. Then I upgraded to libc6 = 2.21-4 (currently latest in
> > > sid). As a result, even the most basic build-time linking would fail.
> > > For instance, with a trivial hello-world program:
> > >
> > > $ gcc-5 -o tst tst.c
> > >
> > > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init'
> > > /usr/bin/ld: final link failed: Bad value
> > > collect2: error: ld returned 1 exit status
> > >
> > > This would happen with gcc-5 and with gcc-4.9. Downgrading libc6 would
> > > fix it. After some fiddling I realized that upgrading to binutils =
> > > 2.25.90.20151209-1 (currently latest in sid) fixes it. I.e. with the
> > > latest libc6 and the latest binutils packages things work.
> >
> > The problem is not introduced by the glibc, but just by the fact that
> > it has been built with a recent binutils version which adds new
> > relocation types on i386 and amd64. This means that ALL static libraries
> > are affected by this problem.
> >
> > > Can the broken combination be prevented with some Conflicts: tags?
> > > Currently this is a trap for the unwary.
> >
> > I therefore don't think we need to fix that at the glibc level. Either
> > we just ignore the problem saying we don't support partial upgrades or
> > we try to find a global way to fix the dependencies for all libraries.
>
> We are working to migrate binutils version 2.25.90.20151209-1 into
> testing asap. If everything goes well it should be the case after the
> 13:52 UTC dinstall run, so a few hours after that on the mirrors.
binutils version 2.25.90.20151209-1 is now in testing, I am therefore
closing the bug.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
[email protected]http://www.aurel32.net
Reply sent
to Aurelien Jarno <[email protected]>:
You have taken responsibility.
(Fri, 18 Dec 2015 13:49:02 GMT) (full text, mbox, link).
Notification sent
to John Aston <[email protected]>:
Bug acknowledged by developer.
(Fri, 18 Dec 2015 13:49:02 GMT) (full text, mbox, link).
Reply sent
to Aurelien Jarno <[email protected]>:
You have taken responsibility.
(Fri, 18 Dec 2015 13:49:03 GMT) (full text, mbox, link).
Notification sent
to Max Kellermann <[email protected]>:
Bug acknowledged by developer.
(Fri, 18 Dec 2015 13:49:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Francesco Poli <[email protected]>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <[email protected]>.
(Fri, 18 Dec 2015 22:09:04 GMT) (full text, mbox, link).
On Fri, 18 Dec 2015 14:46:18 +0100 Aurelien Jarno wrote:
[...]
> binutils version 2.25.90.20151209-1 is now in testing, I am therefore
> closing the bug.
Thanks!
I am another user who was bitten by this bug: I worked around it by
installing binutils from unstable. In the meanwhile this bug report was
being filed.
I wonder: is there anything that can be done in order to ensure that
glibc and binutils will always migrate in lockstep in the future?
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE