GOTO Masanori wrote:
Yes, I think you're correct. I didn't deny your opinion. So I taggedit as wishlist for working future glibc package after sarge.
Whishlist for me means : not a bug. I think if/whenever a NPTL implementation has a pthread related structure size differerent than a linuxthread structure size (or define or enum ), you will have a big problem. Did you even check if it is not already the case NOW?
I will check if I find a posix thread testing suite as anyway I need to run it to insure the currents status is not indeed already broken + I need to test my own generated nptl-static-enabled-cvs-libc.
> Note that I'm feel so not pleasure,
because we're _not_ your subcontractor for your job.
I've learned for long (8 years running debian and having installed it on hundreds machines including MP servers, laptop, ...) to _never_ wait debian for anything. I've been waiting 14 months to have my PPPOA submitted patche integrated into debian PPP to enable debian users to use their ADSL modem for example.
Concerning you working as a subcontractor, see : <http://sources.redhat.com/bugzilla/show_bug.cgi?id=519>I have averything working but will certainly not try to debug the way debian choose to generate its libc-dev especially when I see the gentoo ebuild. I have already a working patched debian/sysdeps/i386.mk to make it generate a nptl-enabled static libc but the resulting nptl library set (crt*.o, *.a) does not work and crash at init somewhere during TLS initialization.
As using the same options on glibc-cvs works, I prefer to go forward as static linking will probably not interfere much with the rest of debian generated applications.
--eric