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 at 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 at cs.net.pl>
> Reply-To: pld-list at mailbox.tuniv.szczecin.pl
> To: pld-list at 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
>