On Sun, Dec 07, 2003 at 02:37:51PM +0100, Arkadiusz Miskiewicz wrote: > On Sunday 07 of December 2003 14:12, Jakub Bogusz wrote: > > > Raczej nie o to chodzi - glibc.spec na HEAD zostało tak zepsute, że > > zbuduje się _co najwyżej_ na x86_64. > Przy okazji tematu można by porozmawiać o kształcie glibc. Obecnie wychodzi na > to, że powinno to być coś w stylu RH ale nie do końca tzn. > > /lib/libc*.so - wersja pthreadsowa (min kernel 2.4.10) > /lib/tls/libc*.so - wersja TLSowa i NPTLowa za razem (min kernel 2.6.0)
OK. > /lib/libc64/libc*.so - wersja 64bitowa na amd64 z TLSem i NPTLem, Dlaczego tak a nie /lib64? (/lib64/tls? [1]) > na sparc64 > prawdopodobnie bez TLS/NPTL (2.6.0) Nie ma? > ia64 nie mamy ale tam wyglądało by to następująco > /lib/libc*.so - TLS+NPTL+2.6.0 kernel > /lib/libc32/libc*.so - jak wyżej czyli TLS+NPTL+2.6.0. Nie /lib32? [1] Nie widzę w tym schemacie wsparcia dla 64-bit + 2.4.x - nie ma zainteresowanych taką kombinacją? > W RH podział jest głebszy, a mianowicie oni mają także wersje pthreadsowe z > TLSem ale bez NPTLa. IMO u nas nie ma to sensu. Raczej nie. > Wersja 32bit i 64bit w jednym pakiecie, a nie tak jak to jest teraz ze sparc64 > gdzie są paczki glibc64, glibc64-devel. Hm, no nie wiem. libc*.so to 1.2MB; posiadanie 2-4 wersji w przypadku korzystania tylko z jednej nie jest zbyt zachęcające. -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ __________________________________________________________ nie pytaj co inni zrobili dla pld, pomysl ile sam zrobiles
