Bug#351629: Still in 2.3.6.ds1-10 with sarge binutils

2007-03-07 Thread Michael Koren
Is there a reasonable way to use an older libc6-dev with a current libc6? I
wouldn't mind using the version from sarge when I want to use gcc-3.3, but
the dependencies don't allow it.

As I asked before, is there a good reason for that (seeing as libstdc++6-dev
doesn't have that restriction), or would that combination work?

Thanks,
Michael



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#351629: Still in 2.3.6.ds1-10 with sarge binutils

2007-03-04 Thread Michael Koren
 Hi, I don't know if I can reopen this as a normal user, but I can
 still reproduce this with libc6-dev from etch and binutils from sarge,

  that's an unsupported mix. there is a gcc-3.3 in etch, binutils in
etch, please install this combination.

I was referring to the problem described by the orignal reporter, i.e., which 
gcc-3.3 doesn't matter, but post-sarge binutils doesn't work:

Error also goes away if binutils is upgraded from sarge version to version
currently in unstable. But this upgrade in turn causes problems with
usage of g++ 3.3, described at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625. This problem happens
on Debian if binutils are post-sarge, with any version of g++-3.3 packages.

So at least, dependency on recent binutils should be added.

But it would be much better if compatibility with sarge binutils will be
preserved in libc6-dev until a workable combination of g++-3.3 and
post-sarge binutils will be found. Unfortunately, we do have to use
g++-3.3 ABI here, and I'm sure we are not alone with that.

I guess this is really a bug in binutils, but it still means this package is 
apparently incompatible with g++-3.3 for now, due to a few mysterious name 
changes in libc_nonshared.a. That leaves no suitable package in etch, hence my 
two questions above.

Thanks,
Michael

P.S. Should a copy of this bug be sent to the binutils package?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#351629: Still in 2.3.6.ds1-10 with sarge binutils

2007-03-01 Thread Michael Koren
Hi, I don't know if I can reopen this as a normal user, but I can still 
reproduce this with libc6-dev from etch and binutils from sarge, as the initial 
report stated. Unless the conflict between newer binutils and g++-3.3 has been 
fixed, that would seem to still leave a problem.

I'm using the original test case:

[EMAIL PROTECTED]:/file/devel/test# gcc-3.3 -shared -o libtest.so test.c
/usr/lib/libc_nonshared.a(atexit.oS)(.text.__i686.get_pc_thunk.bx+0x0): In 
function `__i686.get_pc_thunk.bx':
: multiple definition of `__i686.get_pc_thunk.bx'
/usr/lib/gcc-lib/i486-linux/3.3.5/crtbeginS.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0):
 first defined here
collect2: ld returned 1 exit status

[EMAIL PROTECTED]:/file/devel/test# dpkg -l libc6-dev libc6 gcc-3.3 gcc-3.4 
binutils
ii  libc6-dev   2.3.6.ds1-10GNU 
C Library: Development Libraries and Header Files
ii  libc6   2.3.6.ds1-10GNU 
C Library: Shared libraries
ii  gcc-3.3 3.3.5-13The 
GNU C compiler
ii  gcc-3.4 3.4.3-13sarge1  The 
GNU C compiler
ii  binutils2.15-6  The 
GNU assembler, linker and binary utilities

Aside from upgrading binutils, I found that the following combinations compiled 
and linked without errors:

- gcc-3.4 (with any version of libc6-dev)
- gcc-3.3 after replacing /usr/lib/libc_nonshared.a with the version from 
sarge's libc6-dev
- gcc-3.3 after replacing /usr/lib/gcc-lib/i486-linux/3.3.5/crtbeginS.o and 
crtendS.o with the versions from gcc-3.4 (located in 
/usr/lib/gcc/i486-linux/3.4.4/)

This seems to stem from differences in the functions listed in the error 
message in the files in question; for example see

[EMAIL PROTECTED]:/file/devel/test# egrep -ao 
'[[:print:]]*(thunk|atexit)[[:print:]]*' 
/usr/lib/gcc-lib/i486-linux/3.3.5/crtbeginS.o 
.gnu.linkonce.t.__i686.get_pc_thunk.bx
__i686.get_pc_thunk.bx
[EMAIL PROTECTED]:/file/devel/test# egrep -ao 
'[[:print:]]*(thunk|atexit)[[:print:]]*' 
/usr/lib/gcc/i486-linux/3.4.4/crtbeginS.o

[EMAIL PROTECTED]:/file/devel/test# egrep -ao 
'[[:print:]]*(thunk|atexit)[[:print:]]*' /usr/lib/libc_nonshared.a |grep -vx 
__i686.get_pc_thunk.bx |head -n3
atexit
.text.__i686.get_pc_thunk.bx
atexit.oS/  1168353356  0 0 100644  1088  `
[EMAIL PROTECTED]:/file/devel/test# egrep -ao 
'[[:print:]]*(thunk|atexit)[[:print:]]*' oldlibc_dev/usr/lib/libc_nonshared.a 
|grep -vx __i686.get_pc_thunk.bx |head -n3
atexit
.gnu.linkonce.t.__i686.get_pc_thunk.bx
atexit.oS/  1164718190  0 0 100644  1028  `

So my questions are:

1) Why were these changes made to libc_nonshared.a (in two different minor 
libc6-dev uploads, it seems, including an NMU), and could they be reverted 
again for compatibility with gcc-3.3; and
2) Is there in the mean time any problem with using the older sarge version of 
libc6-dev with a current libc6? The dependency is looser between libstdc++6-dev 
and libstdc++6, for instance, allowing any later version of the latter to be 
used. Is there a specific reason that the libc6-dev-libc6 dependency is an 
equality?

Thanks,
Michael



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]