On Tue, Jun 15, 2004 at 02:37:04PM +0200, Mariusz Mazur wrote: > On wtorek, 15 czerwca 2004 14:34, Jakub Bogusz wrote: > > Jeśli główny powód nie podłączania i386 to brak NPTL, to: > > > > http://sources.redhat.com/ml/libc-hacker/2004-05/msg00019.html > > "One should not install i386 NPTL shared libraries unless on real < i486 > system." > > Branie takiej gimnastyki jako generica bardzo mi się nie podoba.
To mv i586 i486 i wyraźne opisanie, że podstawa to i486, a i386 jest mocno nie zalecane dla >386 (problemy mogłyby wyjść chyba dopiero na SMP, włączając HT). Albo zmodyfikować, żeby w bibliotekach dzielonych też sprawdzał funkcjonalność CPU - będzie mniej wydajnie, ale bezpiecznie wszędzie. W utrzymany port i386 poza automatyką nie wierzę. Podobnie jak utrzymywanie jakichkolwiek kompletnych Ra-packów poza automatyką (np. niedziurawego postgresa czy jąder 2.4.x na wszystkie architektury). Jakie mogą być problemy z kompilacją na i386 w stosunku do i686 (co innego z działaniem na faktycznym i386)? W Ac jedynym powodem jest mosiksowe jądro na builderze. Jeśli boisz się problemów przy kompilacji z powodu braku NPTL, to patrz patch. Ale podobny problem i tak może być z niektórymi architekturami !x86. > > A i tak spodziewam się problemów z NPTL na !x86, bo mało kto to testuje > > przy uaktualnianiu. > > Zakładam, że arch obecnie na topie (ppc/amd64/ia64) powinny sobie radzić. > Oby. W każdym razie od nptla odwrotu nie ma. A sparc? Na razie wychodzi, że generic jest bez NPTL, w porównaniu ze sparcv9 i sparc64 chyba brakuje jednej funkcji(?). alpha - pamiętam, że był problem z kompilacją z TLS (i dlatego nie ma w #ifdefach), IIRC z libc-alpha później rozwiązany. NPTL niby jest, ale czy działający to inna sprawa, bo we wszystkich snapshotach były jakieś błędy na tej architekturze. -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ _______________________________________________________ złota zasada - kto się nie zna, niech się nie wypowiada
