Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-18 Thread Francesco Poli
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


pgpNYwHR9AjNb.pgp
Description: PGP signature


Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-17 Thread Christophe
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


Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-17 Thread Emmanuel Charpentier
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



Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-17 Thread Vlad Orlov
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").

Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-17 Thread Aurelien Jarno
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
aurel...@aurel32.net http://www.aurel32.net



Bug#808181: Re[2]: Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-17 Thread Vlad Orlov
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.

Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-16 Thread Dima Kogan
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.



Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-16 Thread Aurelien Jarno
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
aurel...@aurel32.net http://www.aurel32.net