On Tue, Jan 06, 2004 at 09:31:41PM +0100, Jakub Bogusz wrote: > On Tue, Jan 06, 2004 at 08:21:50PM +0100, Jacek Konieczny wrote: > > ... ale takie co się będzie kompilować oraz będzie poprawnie > > działać zarówno na kernelu 2.4 i 2.6 (wykorzystując możliwości 2.6, > > gdy to możliwe). > > > > W glibcu które dotychczas było na builderach utime() nie działało > > prawidłowo na kernelach 2.4, przez co np. ruby nie budował się na > > niektórych builderach. Z tego powodu (po konsultacji na IRC i z RM) > > puściłem na buildery glibc z HEAD. Na tym glibc ruby kompiluje się > > na np. builderze athlon (gdzie wcześniej się nie kompilował), ale > > samo glibc nie buduje się na builderze alpha. > > > > A alphie budowa glibc wywaliła się przy konsolidacji czegoś związanego > > z TLS. Fajnie by było jakby ktoś to poprawił, jeżeli nie, to będzie > > trzeba TLS wyłączyć. > > Nawet nie wiem gdzie szukać.
objdump -r libc_pic.a | grep '\<TPREL' (na podstawie okoliczności występowania komunikatu "TLS local exec code cannot be linked into shared objects") > libc_pic.a zawiera kilkaset obiektów, błędów jest kilkadziesiąt > - z których obiektów mogą pochodzić??? Wszystkie z malloc.os, dotyczą symbolu __libc_tsd_MALLOC. Jest on definiowany w linuxthreads/sysdeps/pthread/malloc-machine.h. MALLOC jest chyba jedynym definiowanym przez __libc_tsd_define(static, MALLOC) - inne podobne są jako __libc_tsd_define(extern, ...) albo __libc_tsd_define(, ...) (i mają relokacje typu GOTTPREL, obsługiwane w bibliotekach dzielonych). Nie wiem co z tym zrobić - może się kwalifikuje na libc-alpha. -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ __________________________________________________________ nie pytaj co inni zrobili dla pld, pomysl ile sam zrobiles
