Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: lug-bg: gcc error - Segmentation Fault (program cpp0)


  • Subject: Re: lug-bg: gcc error - Segmentation Fault (program cpp0)
  • From: yaneti@xxxxxxxxxxx (Yanko Kaneti)
  • Date: 16 Feb 2002 14:01:36 +0200



Ne moga da se sdurja da ne vmetna nyakoi dumi za redhat i pr.

On Sat, 2002-02-16 at 09:35, George Danchev wrote:
> On Friday 15 February 2002 04:18, you wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Thursday 14 February 2002 20:45, you wrote:
> > > On Thursday 14 February 2002 19:29, you wrote:
> > > > Pri kompilacija na kernel ili drug paket (BIND 9.2.0 naprimer)
> > > >
> > > > OS: Red Hat Linux 7.2
> > > > gcc ver.2.96
> > > > kernel 2.4.7; 2.4.9
> > > >
> > > > mashinata e Pentium 150, o/c na 188, 64MB RAM.
> > > >
> > > > 10x predvaritelno!
> > >
> > > ami tokova zhivotno kato gcc-2.96 nqma officialno release-nato ot
> > > developers na gcc (vizh na site-a na gcc za da se ubedish). RH sa vzeli
> > > edin CVS snapshot na gcc nqkyde okolo 3.0 patch-nali sa go zdravo (s
> > > eksperimantalna cel maj, neznam) i v rezultat na koeto tova gcc e zdravo
> > > broken i e predvideno samo za user space kompilacii, a ne na kernels :).
> > > Oba4e s RH 7.2 trqbva da vyrvi i kgcc (tova maj e istinskoto gcc2.95 , ne
> > > sym mnogo siguren za versiqta no e naistina ot upstream developers na
> > > gcc) . Ta s tri dumi:

Na tova kakto i na spekulaciite po-dolu okibknoveno se otgovoaraya s eto
tova url http://www.bero.org/gcc296.html

> > > smqna na gcc s nesto po-4oveshko - 2.95.3 , 2.95.4
> > > smqna na kernela - vanilla >=2.4.10  (bez 2.4.11 i 2.4.15)
> > > [mislq 4e kernela kojto idva s RH 7.2 e 2.4.9-ac, smenqj go smelo s nqkoj
> > > vanilla, stoto ina4e si s forked kernel - s stara VM i t.n. i po-malko
> > > hora go nabludavat i pomagat pri problemi... poslednite vanilla 2.4 sa
> > > dosta koravi, vypreki 4e az neiskam da se razdelqm s moq 2.4.10 zvqr ;]

Distribuciite obiknoveno izbirat kernela koito e po-stabilen (t.e. bil e
stress testvan sus razlichen harware). Taka che ako -ac seriyata kerneli
raboti za redhat veroyatnosta da raboti _za men_ e po-golyama ot tazi na
koito i da e vannila kernel.
kgcc koeto redhat shipvat  vuv 7.x e egcs 1.1.2 = gcc 2.91.66. ,
kompilatora na rh6.x

> > Hmm.
> > gcc-2.96 koeto idva s RH-7.2 ne bi triabvalo da ima problemi. ( Ili pone ne
> > 4ak tolkova seriozen  problem ). Po4ti edin mesec karah s nego.
> > Po skoro  mi prili4a kato OOM killer-a da se "razvihria". Vypreki 4e s RH
> 
> gcc naistina se stremi da usvoqva kolkoto se mozhe pove4e pamet (za da 
> priklu4i po-byrzo s kompilaciqta), no go pravi taka da se kazhe dosta 
> kulturno i zakonno, ne iziskva ot kernel-a da mu zadelq vse pove4e i pove4e 
> pamet do bezkraj ako tova naistina ne e vyzmozhno. Ne mislq 4e tova e 
> problema. A OOM killer-a ne pribyrzva s izbivaneto na bad procesite i 
> sotvetno da izduha (iz4isti) heap-a im ot pametta 4e da osvobodi zaetite ot 
> tqh mempages... toj polzva dosta slozhen algoritym i si znae rabotata (koga 
> da kolq i besi:)
> 
> > idva kgcc - koeto e gcc-2.91-neshto si ako si compile-vash vanila kernel
> > shte se polzva gcc-to.Probvai da compilirash bez da puskash X i razni
> > sharenii. Ogledai dali predi da SEGFAULT-ne gcc-to ne ti dava niakakvi
> > syobshteniq za greshi v coda koito compilirash. Dori i "vanila" 2.93 ima
> > edin kup bugove koito kato stigne do greshka ot koiato ne moje da se
> > vyzstanvi compilaciata oshte mnogo redove programen cod SEGFAULT-va.
> 
> li4noto mi nabludenie e 4e gcc 2.95.3 i 2.95.4 sa zheleznite compilers kym 
> momenta. Kakvoto im dadesh go smilat i proizvezhdat naistina stable izpylnim 
> kod. a edno ot dobrite obqsneniq za gcc 2.96:
> http://www.mplayerhq.hu/DOCS/faq.html
> http://www.mplayerhq.hu/DOCS/gcc-2.96-3.0.html
> http://www.mplayerhq.hu/DOCS/users_against_developers.html

Struva mi se devloperite na mplayer izpolzvat edin kup dumi za da kajat
prosto "ne znam", za da opravdayat anti redhat nastroeniyata si  i da
izbyagat ot problemite na potencialnite potrebiteli  vmesto da napravyat
nyakakuv opit da gi reshat.

> ina4e oplakvaniq ot nego mnogo... a eto i kakvo e kazano v 
> Documetation/Changes v 2.4.10 kernela v slu4aj 4e nqkoj nqma source na 2.4 
> pod ruka. A preporukite za kernela sa dobra otpravna to4ka za tova kyf da e 
> compiler-a (kojto da kompilira ne samo kernel razbira se). 
> 
> The recommended compiler for the kernel is gcc 2.95.3 or .4, and it
> should be used when you need absolute stability. You may use gcc 3.0.x
> instead if you wish, although it may cause problems. Later  versions of gcc
> have not received much testing for Linux kernel compilation, and there are
> almost certainly bugs (mainly, but not exclusively, in the kernel) that
> will need to be fixed in order to use these compilers. In any case, using
> pgcc instead of egcs or plain gcc is just asking for trouble.
> 
> Note that gcc 2.7.2.3 is no longer a supported kernel compiler. The kernel
> no longer works around bugs in gcc 2.7.2.3 and, in fact, will refuse to
> be compiled with it. egcs-1.1.2 has register allocation problems in very
> obscure cases. We have ensured the kernel does not trip these in any known
> situation. The 2.5 tree is likely to drop egcs-1.1.2 workarounds.
> 
> The Red Hat gcc 2.96 compiler subtree can also be used to build this tree.
> You should ensure you use gcc-2.96-74 or later. gcc-2.96-54 will not build
> the kernel correctly.

> [az bih kazal zabravete za gcc-2.96, a ako go polzvate naj-dobriq izto4nik za 
> otgovori otnosno problemi sa RH - tehnite mail lists i t.n., ama tova rabota 
> li e ?!]

Koe tochno te pritesnyava otnosno komunikaciyata s redhat?
https://www.redhat.com/apps/support/resources/ ?
https://www.redhat.com/mailing-lists/  ?
https://bugzilla.redhat.com/bugzilla/  ?

Moje i da ne izpipvat vsichko dokrai, zashtoto sa vse pak sa komersialna
organizaciya, imat srokove, po-vajni i po-malovajni klienti  i t.n. 
obache sus sigurnost ne sa hora koito byagat ot problemite  ili puk te
lujat v liceto che vsichko raboti.
 
> zabravih da kazha 4e na edno ot CD-tata na RH-7.2 ima i hacked versiq na 
> glibc (hacknata ot RH razbira se)... edin mnogo knoledgeble tip ot tqh go e 
> predlozhil i izpylnil, nari4at go object prelinking - neznam kakvo zna4i i 
> kakvo sa promenili, no s nego prilozheniqta startirat adski byrzo no pyk za 
> tova mogat i da brake-vat adski byrzo , vse oste e experimental oba4e... vizh 
> da ne si s tova glibc - vsystnost ideq nqmam kak ste go poznaesh :) 

Ulrich Drepper - maintainera na glibc kakto i Jakub Jelinek ako ne se
luja choveka su spomenatiya preload hack rabotyat za redhat, ako shte
"probvam" nechii hackove to nai veroyatno da sa tehnite ;)

> Vsi4ko tova go kazvam ne 4e imam nesto protiv RH, a zastoto v tehnite distros 
> ima dosta iznenadi (dosta forked upstream sources, bez da ima realna pri4ina 
> za tova v pove4eto slu4ai)... ponqkoga poor documented i user-a se 4udi kakvo 
> i zasto stava ... report-va bugs , oba4e drugite kojto ne polzvat RH ne mogat 
> da go reproducirat i syotvetno bug-a se prevrusta v mystery ... idi 4e 
> razberi. Imat mail lists kydeto se obsyzhdat podobni RH specific probs.

Nyakakvi fakti koito da podkrepyat tvurdenieto v skobite? Kazvash
forked, a realno nyama nikakvi seriozni forkove na samiya kernel ili na
glibc. Osven ako ne smyatash -ac seriyata za seriozen fork, no az vse
pak bih vyarval na Alan Cox za tova dali moje da se schita za fork.

Ot tova koeto az sum vijdal (a to vsichko e publichno) redhat vzema gore
dolu stabilna versiya na kernela/glibc, patchva ya po vsyakakuv nachi da
stane po-stabilna i da raboti s poveche hardware  (kto za tova izpolzva
patchove po sledvashti versii na kernela) , testvat seriozno poluchenata
banica, i go puskat kato osnoven kernel/glibc na distribuciyata si. 

Ako nyakakva po seriozna nesuvmenstimot ne prechi na po natatushnoto
upgradvane na paketa to se puskat versii sus sledvashti versii na
kernela, primer  kernel-2.4.9-13.i686.rpm   za redhat 7.2

> problema mozhe i hardwaren da e - pametta, no 4oveka se e testval sigurnove4e 
> s memtest86...... No  naistina edin 4ist install na RH s gcc != 2.96 i 
> normalno glibc mozhe da pomogne - znaesh li kakvo e broken. Ako isksh probvaj 
> da instalirash gcc-2.95 ot binary .rpm .
> Ili install na nqkoe drugo _4isto_ distro za test, da se vidi kva ste e 
> reakciqta. 

Problema na choveka izglejdashe kato bug vuv pametta, no toi kaza che ya
e testval. Ako priemem che hardwera e zdrav znachi sledvashtoto neshto
koeto moje da e skapano e gcc-to mu.  
Logichna stupka za vseki rh user e da vidi dali ima update na gcc-to ot
redhat. Ako tova ne pomogne sledvat razlichni kombinacii ot
troubleshoooting, vsichki zaviseshti ot nalichieto na svobodno vreme i
nivoto na znaniya na potrebitelya. 

Problemi ima razni i raznoobrazni, i te ne sa ogranicheni do rh gcc
2.96. Sus distro bashing obache ne reshavame nito edin ot tyah.

Pozdravi
Yanko 
===========================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers)
http://www.linux-bulgaria.org/ Hosted by Internet Group Ltd. - Stara Zagora



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.