From: Clint Adams [EMAIL PROTECTED]
Date: Sun, 11 Dec 2005 17:41:55 -0500
Replacing Aurelien's patch with this one fixes the
/lib64/libc.so.6: error while loading shared libraries: unexpected reloc type
0x4f
problem, and /lib64/libc.so.6 --version works fine.
However, 64-bit binaries
Package: libc6-sparc64
Version: 2.3.5-8
Severity: normal
There are some critical things missing in the sparc64 TLS support code
in the current debian glibc tree, for example none of the TLS
relcation support is in sysdeps/sparc/sparc64/dl-machine.h, and
therefore so no binary linked against
From: Bernd Eckenfels [EMAIL PROTECTED]
Date: Sun, 14 Aug 2005 19:51:39 +0200
I have this error report on ifconfig (also a problem with ip link) that a
down interface receives packets. I remeber this was discussed before but
cannot find a result of the outcome. Is this a driver problem?
From: Jim Crilly [EMAIL PROTECTED]
Date: Tue, 24 May 2005 14:42:27 -0400
True, but building kernels on sparc64 wasn't terribly fun for me the last
time I tried it either so I decided it wasn't worth it and just stuck with
the Debian kernel images.
Amusing as I do all of the sparc64 kernel
From: Ben Collins [EMAIL PROTECTED]
Date: Tue, 24 May 2005 14:29:16 -0400
And what about building kernels? They will by default be building
sparc32 kernels. That's the most likely place for this to be a
problem.
People can't wrap their brain around how to build a sparc64
kernel often right
From: [EMAIL PROTECTED]
Date: Mon, 23 May 2005 13:24:18 -0700
The other alternative is to touch /etc/disable_64_gcc
Sure, but in the mail you are specifically replying to I stated:
Also, /etc/disable_64_gcc is a workaround and should not be there
by default as it is now, especially on your
From: Ben Collins [EMAIL PROTECTED]
Date: Mon, 23 May 2005 20:21:57 -0400
But (and this but is for David), that means users can't simply do
apt-get source foo; cd foo-1.1; dpkg-buildpackage and get the same build
they got from us, which is a consistency Debian needs. Maintainers trying
to fix
On Sat, 21 May 2005 14:06:52 +0200
Falk Hueffner [EMAIL PROTECTED] wrote:
this bug has been open for quite some time as important. Can some
sparc people please comment on it?
This is not a bug, it should be closed. On sparc64, gcc should emit
64-bit code by default. If you want 32-bit code
From: Thiemo Seufer [EMAIL PROTECTED]
Date: Sun, 22 May 2005 01:37:50 +0200
David S. Miller wrote:
[snip]
This is not a bug, it should be closed. On sparc64, gcc should emit
64-bit code by default. If you want 32-bit code emitted on a sparc64
system you have exactly two options 1) add
On Fri, 29 Apr 2005 11:48:07 +0200
Frans Pop [EMAIL PROTECTED] wrote:
One problem is that the Mostek RTC driver currently does not support the
RTC_(RD/SET)_TIME. However, the thread contains a patch that will fix
this. I am not completely sure if this patch is final yet or if has will
be
On Sat, 16 Apr 2005 03:10:17 -0400 (EDT)
Jurij Smakov [EMAIL PROTECTED] wrote:
Please review and apply if it makes sense :-).
Looks good, I'll apply this.
Thanks Jurij.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Mon, 14 Mar 2005 22:21:53 -0500
Joey Hess [EMAIL PROTECTED] wrote:
Yes, but I didn't realize that it was probably a non-bug. Do you think I
ought to revert that then?
I think so, just autoloading modules to work around incorrect
SBUS module loading isn't such a good idea.
Ben didn't
On Mon, 14 Mar 2005 23:57:08 -0500 (EST)
Jurij Smakov [EMAIL PROTECTED] wrote:
It only looks for (and scans for devices on) the first one
it finds. I am reassigning this report to dicover1 and will try to cook up
a patch for that.
Perfect. sun4d systems would need such a fix as well, they
13 matches
Mail list logo