Call for hardware (pld3.0 Wc)

[Jakub Bogusz]

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/