B³±d w glibc?

[Marcin Dalecki]

Tomasz K³oczko wrote:
> 
> On Tue, 2 Mar 1999, Marcin Dalecki wrote:
> [..]
> > Odpowiedni± ³atê na egcs.spec dawno dawno temu ju¿ przecie¿ ¿uci³em na
> > t± listê...
> 
> Owszem. Trochê siê zachowa³em po gapiosku. Wojtek gada³, ¿e ma k³opoty z
> tym patchem i za³o¿y³em, ¿e ostatnia wersja egcs jaka by³a na magellanie
> nie mia³a ju¿ tej "modyfikacji". Widac nie zd±¿y³ ju¿ tego zrobiæ, a ja
> poprostu te¿ nie sparawdzi³em.
> 
> Przy okazji .. jest ju¿ w zasadzie nowe binutils. Czy jest jaka¶ potrzeba
> siêgania wy¿ej ni¿ to co mamy teraz (teraz jest 2.9.1.0.19a, a jest
> dostêpna chyba 22b, a na pewno 21) ? I jeszcze jedna rzec zwi±zana z egcs

Nie traktuj proszê zbyt powa¿nie freshmeata 2.9.1.019a to ostatnia
stabilna wersja. No owszem HJLu zwykle zanim co¶ publikuje to robi
solidne
testy tak wiêc je¶li kto¶ chce to mo¿e stosowaæ nowsze wersje. Jednak
nie widzê ku temu jak narazie pilnej potrzeby. Wszystkie nowostki
zwi±zane 
z C++ w egcs-ie s± w binutils-2.9.1.0.19a ju¿ wspomagane.
Nastepne wersje maj± opierac siê ju¿ na wy¿szych wersjach
binutils-2.9.2.

Nie podzielam równie¿ wyra¿anych tu pogl±dów co do ¿ekomo 
w±tpliwej jako¶ci glibc-2.1.
W porównaniu z glibc-2.0.7b6 jest to krok milowy naprzód. 2.0.x by³y
znacznie
bardziej zawszawione ni¿ libc-5.4.xx HJLu. No oczywi¶cie abstrahuj±c od
wspomagania wielow±tkowo¶ci, co jednak w praktyce nie jest a¿ tak
istotne,
albowiem programy wyko¿ystuj±ce to faktycznie dopiero co zaczynaj± siê
pojawiaæ
a i tak nigdy nie bêdzie ich zbyt wiele (podobnie jak maszynek
wieloprocesorowych...)
(patrz: moje  poprzednie opinie na temat pisania programów dla systemów
masywnie  wieloprocesorowych)

> i binutils. W obu tych rzeczach jest libiberty.a ale wygl±da na to, ¿e
> wersja z egcs jest ¶wie¿sza. Zawsze by³em przekonany, ¿e libiberty.a to
> czê¶æ binutils.  Samo libiberty zawiera chyba rzeczy które chyba s± ju¿
> glibc (?) wiêc chyba w obu tych pakietach mo¿na zrezygnowaæ z
> dystrybuowania tej biblioteki ?

Lib-iberty to takie co¶, ¿e w ka¿dym pakiecie jaki to stosuje mie¶ci siê
nieco inna wersja tego¿. Tak wiêc nie ma praktycznie szans na
jakiekolwiek
wspó³dzielenie tej biblioteki. Nawet radzê srogo uwa¿aæ, bo nie zawsze
numer
wersji tej bibliteki oddaje faktyczny jej rozwój!
Jest ona wiêc zbêdna w instalacji. Wypowiada³em siê ju¿ na ten temat w 
zwi±zku z ³at± na egcs.spec. Albowiem usun±³em równie¿ instalacjê
libiberty w tym specu.

Dla informacji: libiberty ma niby zawieraæ portabilijna otoczki na
syscall-e nieco siê ró¿ni±ce pomiêdzy systemami. W rzeczywisto¶ci jest
to
po prostu taki sobie zlepek czego¶ tam, a w wiêkszo¶ci zbêdnych
x-wrapperów
na malloc, strdup itp. (vide xmalloc xstrdup  itp.) oraz z rodzinki
memset, bzero, memmove bcopy itd.... Zbêdne, bo malloc np.
wali siê gdy juz naprawdê nie ma pamiêci i próbowanie od³apania tego 
b³êdu poza zwyk³ym errno nie ma zbyt wiele sensu, albowiem je¶li malloc
zwróci NULL, to przy pierwszej lepszej okazji (czyli zwykle
inicjalizacji
w wierszu tu¿ po nim) walnie siê program tak czy siak w sposób bardzo 
³atwy do wykrycia przy pomocy debuggera. W systemie z wirtualn±
przestrzeni
adresowania wal±cy siê malloc pokazuje nam jedynie, ¿e nied³ugo ca³y
system
szlag trafi. Tak wiêc próby reagowania na to s± tak czy siak do¶æ
beznadziejne...


PS. W³a¶nie implementujê w robocie co¶ takiego jak ograniczenie liczby
procesów
u¿ytkownika i ograniczenie czasu CPU dla jego procesów w linux-ie. Czyli
takie
uproszczone process-quotas. Bardzo mi³a sprawa we wrapperach suexec do
skryptów
na serwerach obs³uguj±cych wielu klientów. Zainteresowany?

--Marcin