so that maintainers could apply them to architecture-specific bugs when
necessary. The format, suggested by Steve Langasek, was to use the
porters mailinglist as the user, and the architecture name as the
usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as
tag).
Armel has alread
I haven't had an opportunity to run the test yet (my laptop currently
grinding away building the new release of GCC for m68k) but threads on Linux
when using linuxthreads to my knowledge are almost completely in userland;
linuxthreads uses clone() to create them. If it requires real-time signals
o
Problem would be rather missing memory barier, or non-atomic operation.
This should be fixable even with 2.5 glibc and linuxthreads.
Do we need a fix in linuxthreads, or the kernel?
I don't know.
The linuxthreads add-on is currently used
by hppa and kfreebsd-* for glibc 2.7.
But the latest e
Hi from GNU/kFreeBSD porter.
After talking it over with stephen and arranging perl 5.10 to be built on
real metal vs aranym, we are pleased to report that perl passes its test
suite with the exception of one test, a threading stress test which
launchs multiple threads, and then tries to make su
I think glibc 2.3.999 needs some attention a some point:
http://experimental.ftbfs.de/build.php?arch=m68k&pkg=glibc
Well, glibc 2.5 currently in experimental should be buildable on m68k.
The number of places which required TLS have been small. Someone should
test it, post result here and get bu
I am also tagging this bug "help" as I am waiting a patch from the m68k
porters to support thread local storage, as already asked on the
debian-m68k mailing list.
As far as I know, only two places in glibc 2.5 require __thread:
inet/inet_ntoa.c and malloc/memusage.c
The "fix" for first one co
6 matches
Mail list logo
