B³±d w glibc?

[Piotr Zurawski]

AFAIK, to pgcc stosuje jakies dziwne, "faszystowskie" optymalizacje (jak
to ujal pewien mily mlody czlowiek) ktore nie zawsze dobrze odbijaja sie
na sprzecie osob uzywajacych tych programow. Jak sie domyslam, problem
moze lezec w roznicy architektur, tzn. developer kompilujac program na
pgcc na maszynie klasy i686 ma automatycznie powlaczane przez kompilator
optymalizacje pod taki sprzet, wiec w przypadku pakietow, ktorych
dzialanie nie ma kluczowego znaczenia, wystapi blad, program zrzuci cora i
uzytkownik prawdopodobnie sam przekompiluje pakiet.... ale w wypadku
bibliotek systemowych osobiscie uzywam gcc 2.7.2.3 , a optymalizacje,
ktorych uzywam to -O3 -fexpensive-optimizations, a w celach debugowania
daje -g iWall . Mysle, ze takie pakiety, jak kompilatory i biblioteki
systemowe powinny byc kompilowane ze wsparciem dla slabszych procesorow
tj. i486, chyba, ze zakladamy, ze PLD bedzie chodzilo na maszynach i586 i
w gore...

-- 
Piotr Zurawski AKA szur
Administrator sieci
szur w ix.renet.com.pl


On Tue, 2 Mar 1999, Marcin Dalecki wrote:

> Date: Tue, 02 Mar 1999 13:56:17 +0100
> From: Marcin Dalecki <dalecki w cs.net.pl>
> Reply-To: pld-list w mailbox.tuniv.szczecin.pl
> To: pld-list w mailbox.tuniv.szczecin.pl
> Subject: Re: [iso-8859-1] Błąd w glibc?
> 
> Jacek Osiecki wrote:
> > 
> > Witam!
> > 
> > Znalazłem coś, co mi się raczej nie podoba...
> > 
> > Mam PLD zainstalowane od zera. Czyli standardowo glibc-2.1-3d i gtk+ oraz
> > glib w wersjach 1.1.15.
> > 
> > Jest sobie programik w gtk+. No i jest jego fragment:
> > 
> > ev=gdk_event_get();                /* wait for event */
> > fprintf(stderr,"MARK 1\n");
> > if (ev->type == ev->type) fprintf(stderr,"test 1 OK\n");
> > if (ev->type == GDK_KEY_PRESS) fprintf(stderr,"test 2 OK\n");
> > fprintf(stderr,"MARK 2\n");
> > 
> > Po skompilowaniu, program działa tak:
> > 
> > MARK 1
> > test 1 OK
> > Naruszenie ochrony pamięci (core dumped)
> > 
> > Powiedziałbym, że dosyć dziwne...
> > 
> > Dalej: co mówi gdb ./a.out core
> > 
> > [...]
> > Program terminated with signal 11, Naruszenie ochrony pamięci.
> > [...]
> > #0  0x804b57f in jump2image ()
> > (gdb) bt
> > #0  0x804b57f in jump2image ()
> > #1  0x113 in ?? ()
> > #2  0x4025ebac in __libc_start_main ()
> > #3  0xe8 in ?? ()
> > (gdb)
> > 
> > No to by było na tyle. Dalej się poddaję i nic nie poradzę :(
> > 
> > P.S. To samo działo się, gdy w ramach testu zrobiłem upgrade do glib/gtk+ do
> > 1.2, oraz imlib-1.9.3.
> > Gdy próbowałem zrobić upgrade glibc i glibc-devel do dostępnych na
> > ftp.task.gda.pl/pub/linux/PLD/stable/i386 glibc-2.1-4, to zaczęły się dziać
> > jaja nie z tej ziemi :( Co drugi programik dawał komunikat "Błędna
> > instrukcja" (czy może "nieprawidłowa"), a ten programik w gtk+ w ogóle nie
> > chciał się skompilować (pod koniec kompilacji ten sam komunikat "błędna
> > instrukcja").
> 
> Wszystko wskazuje na to, ze sotsujesz glibc i inne pakiety ktore
> zostaly przekomiplowane kompialtorem zawierajacym bledy.
> 
> Goraco polecam odczepienie sie od pcc, to krotko mowiac chlam...
> 
> Najprawdopodobniej binaria jakie sciagnales sa jeszcze nadal
> nim wlasnie przekompilowane.
> 
> Ponadto nie wlaczaj za cholere przy kompilacji -march=pentiumpro.
> Nie wszystkie processory wykonyja instrukcje dostepne tylko na
> pentiumach intel'a.
> 
> --Marcin
>