Chapu tenhle clanek dobre tak, ze nektere veci prelozene s glibc-2.1 nebudou fungovat s glibc-2.2 ? Jestli je to tak, tak to mam fakt radost, jako by nestacilo, ze se bude muset znovu prelozit vsechno napsane v C++ kvuli gcc.
nevim proc by se mnelo vsechno znovu prekladat, vzdyt system dynamickeho linkovani nabizi jednoduche reseni - proste mit na disku jak glibc 2.1 tak 2.2. Bohuzel, balikove systemy na to nejsou stavene - IIRC rpm -U smaze predchozi verzi programu vcetne knihoven. Jinak nevim presne co konkretne jste musel kvuli gcc prekladat znovu - posedni oficialni release je gcc 2.95.3 a to by mnelo byt binarne kompatibilni i s egcs. Pokud pouzivate nestabilni redhatovskou 2.96-XX pak je to ovsem o necem jinem :)
Ne. Glibc 2.2 s programy slinkovanymi pro 2.0 nebo 2.1 bude fungovat OK (mela by... nebude, pokud programator byl prase a pouzil interni funkce z glibc misto tech z verejneho API ;). Tady byl problem s upgradem RPM, _ten_ zbori zavislosti.
Ja nechapu jinou vec: proc je nutne upgradovat RPM na 4.0, kdyz upgraduji glibc? Obzvlaste kdyz RPM 3.0.5 format baliku pro ctyrku zvlada...?
snad by to nemel byt vubec zadnt problem aspon podle toho co se pise ve FAQu glibc2.0 s nejakym oznacovanim symbolu verzemi primo v knihovne... uz to jde ale trosku mimo me, takze radsi vic o tom ve FAQ,README,INSTALL primo ve zdrojakach glibc.
