Package: libc6
Version: 2.3.5-6
Severity: normal
ppc32 glibc has a problem when running with a ppc64 kernel with 64k
pages support enabled. This is fixed in upstream glibc CVS already (64k
pages support isn't yet available in the released kernels, but I'll
release the patch soon and it would be
The bug has been fixed in gcc (though it may not have hit 3.4 CVS yet).
See debian #307993 for details. This bug was causing any arch to die
when building glibc with -g1, it's a gcc 3.4 regression, and now that
it's fixed, it should be possible to switch the 2.3.5 package to gcc 3.4
(well, at
gcc-3.4 tst-fini1mod.c -c -std=gnu99 -O2 -O3 -Wall -Winline
-Wstrict-prototypes -Wwrite-strings -fstrict-aliasing -g -g1 -pipe
-mnew-mnemonics
-fpic-I../include -I.
-I/home/benh/glibc-2.3.5/build-tree/powerpc-nptl/nptl -I.. -I../libio
On Sat, 2005-05-07 at 02:39 -0400, Daniel Jacobowitz wrote:
Looks like our gcc-3.4 isn't quite there yet ...
Huh. I've never seen that one before; yeah, file a bug, I suppose.
Just did, it's debian bug #307993
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Bug 307985 is actually caused by this lack of NTPL. I've tried building
it here but got a gcc ICE, see comments in that other bug.
This one can probably be marked as dup.
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libc6
Version: 2.3.5-1
Severity: normal
glibc should be built with TLS/NPTL for ppc nowadays, since we finally
get a recent enough version (it was implemented upstream years ago and
other major distros had it for some time now).
-- System Information:
Debian Release: 3.1
APT prefers
Package: libc6
Version: 2.3.5-1
Severity: normal
The 2.3.5-1 ppc build present in experimental has a problem with
libpthread-0.10.so binary. For some reason I haven't been able to
explain, it lacks the version GLIBC_2.3.3 symbol (it does have 2.3.2
and 2.3.4 and libc6 itself has them all).
This
On Fri, 2005-05-06 at 23:09 -0400, Daniel Jacobowitz wrote:
On Sat, May 07, 2005 at 12:42:02PM +1000, Benjamin Herrenschmidt wrote:
Package: libc6
Version: 2.3.5-1
Severity: normal
The 2.3.5-1 ppc build present in experimental has a problem with
libpthread-0.10.so binary. For some
/usr/bin/gcc still doesn't have PPC TLS support. Does glibc default to
using 3.4 nowadays? Smart choice I guess.
I got bitten by that :) glibc package rule is hard coded to gcc-3.3
which doesn't do __thread. I just changed it to gcc-3.4 and restarted
the build, news in about 1h...
I think
Hi !
I read that:
The attached patch adds powerpc64 support to the snapshot glibc. The
powerpc64 lib is tls, as we do not support 2.4 kernels. 32bit nptl is
disabled, it only segfaults.
What is the snapshot glibc ? what upstream codebase ? Current CVS HEAD ?
I would strongly recommend for now
On Sat, 2004-09-25 at 11:44, GOTO Masanori wrote:
Hi,
At Wed, 15 Sep 2004 14:51:00 -0500,
Stephen R. Marenka [EMAIL PROTECTED] wrote:
asm/setup.h contains #include asm-m68k/setup.h,
which is non-existent on ppc.
Then what's the problem? I guess you didn't get any problems; if so I
Package: libc6
Version: 2.3.2.ds1-12
Severity: normal
TLS and NPTL have been available for PPC for a year at least now and
other distros are using them without trouble. Only a few libs need
updating and it's backward compatible. Why are we stuck to libpthread
on PPC ? Especially in unstable
Package: libc6
Version: 2.3.2.ds1-12
Severity: normal
Followup-For: Bug #146489
Cache management was reworked fixed upstream for ppc, including
this problem.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
As I've explained to a lot of people now, because our GCC 3.3 does not
support TLS.
We can not switch until we're ready to make changes to the default
compiler, which would be inappropriate in this stage of the release
process. I think.
Hrm... Not sure about 3.3 upstream. I though it
Package: libc6
Version: 2.3.2.ds1-12
Severity: normal
TLS and NPTL have been available for PPC for a year at least now and
other distros are using them without trouble. Only a few libs need
updating and it's backward compatible. Why are we stuck to libpthread
on PPC ? Especially in unstable
Package: libc6
Version: 2.3.2.ds1-12
Severity: normal
Followup-For: Bug #146489
Cache management was reworked fixed upstream for ppc, including
this problem.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
As I've explained to a lot of people now, because our GCC 3.3 does not
support TLS.
We can not switch until we're ready to make changes to the default
compiler, which would be inappropriate in this stage of the release
process. I think.
Hrm... Not sure about 3.3 upstream. I though it
Package: libc6
Version: 2.3.2.ds1-11
Severity: normal
Followup-For: Bug #146489
The kernel now do invalidate icache for blank pages, but there
is still a window of oportunity for the icache to get polluted. The
PowerPC processor is allowed to (and will very agressively with recent
Package: libc6-dev
Version: 2.3.1-17
Severity: normal
Software that use the _syscallN macros in asm/unistd.h provided
by glibc on PPC32 won't build with gcc3.3 (typically the MacOnLinux
runtime environement is affected).
The fix is to get the version of those macros in Marcelo's
current
On Fri, 2003-05-23 at 15:55, Randolph Chung wrote:
Software that use the _syscallN macros in asm/unistd.h provided
by glibc on PPC32 won't build with gcc3.3 (typically the MacOnLinux
runtime environement is affected).
asm/unistd.h is not a glibc header and _syscallN() are not supposed to
20 matches
Mail list logo
