# perche' qt non compila?

## dnix

perche' voglio installare gnome o frozen bubble o xine (tutti pacchetti di vitale importanza) e loro tentano di instalarmi le qt3 ma sono 3 giorni che qt non riesce a compilarsi? dovro' tornare al caro vecchio debian?

----------

## Peach

potresti provare a postare l'errore?

magari anche le tue CFLAGS...

----------

## dnix

g++ -c -pipe -fno-exceptions -Wall -W -O2 -D_REENTRANT -fPIC -DQT_SHARED -DQT_TA BLET_SUPPORT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_THREAD_SUPPORT -D_LARGEFILE_ SOURCE -D_FILE_OFFSET_BITS=64 -DQT_BUILTIN_GIF_READER=1 -DQT_NO_STYLE_MAC -DQT_N O_STYLE_AQUA -DQT_NO_STYLE_INTERLACE -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_COMPA CT -I/home/portage/portage/qt-3.1.2-r3/work/qt-x11-free-3.1.2/mkspecs/linux-g++ -I. -I/usr/include/freetype2 -I../include -I/usr/X11R6/include -I/usr/X11R6/incl ude -I.moc/release-shared-mt/ -o .obj/release-shared-mt/qhbox.o widgets/qhbox.cp p

widgets/qheader.cpp: In member function `QRect QHeader::sRect(int)':

widgets/qheader.cpp:168: internal error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

make[1]: *** [.obj/release-shared-mt/qheader.o] Error 1

make[1]: *** Waiting for unfinished jobs....

make[1]: Leaving directory `/home/portage/portage/qt-3.1.2-r3/work/qt-x11-free-3 .1.2/src'

make: *** [sub-src] Error 2

!!! ERROR: x11-libs/qt-3.1.2-r3 failed.

!!! Function src_compile, Line 117, Exitcode 2

!!! (no error message)

--------------------------------------------

questo compare compilando:

>>> emerge (1 of 11) x11-libs/qt-3.1.2-r3 to /

>>> md5 src_uri  :Wink:  qt-x11-free-3.1.2.tar.bz2

>>> Unpacking source...

>>> Unpacking qt-x11-free-3.1.2.tar.bz2 to /home/portage/portage/qt-3.1.2-r3/work

-----------------------------------------------

e le mie CFLAGS:

#

#CFLAGS="-mcpu=athlon-xp -O3 -pipe"

CFLAGS="-march=athlon-xp -O3 -pipe"

# If you set a CFLAGS above, then this line will set your default C++ flags to

# the same settings.

CXXFLAGS="${CFLAGS}"

grazie!

----------

## Gavrila

 *dnix wrote:*   

> g++ -c -pipe -fno-exceptions -Wall -W -O2 -D_REENTRANT -fPIC -DQT_SHARED -DQT_TA BLET_SUPPORT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_THREAD_SUPPORT -D_LARGEFILE_ SOURCE -D_FILE_OFFSET_BITS=64 -DQT_BUILTIN_GIF_READER=1 -DQT_NO_STYLE_MAC -DQT_N O_STYLE_AQUA -DQT_NO_STYLE_INTERLACE -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_COMPA CT -I/home/portage/portage/qt-3.1.2-r3/work/qt-x11-free-3.1.2/mkspecs/linux-g++ -I. -I/usr/include/freetype2 -I../include -I/usr/X11R6/include -I/usr/X11R6/incl ude -I.moc/release-shared-mt/ -o .obj/release-shared-mt/qhbox.o widgets/qhbox.cp p
> 
> widgets/qheader.cpp: In member function `QRect QHeader::sRect(int)':
> 
> widgets/qheader.cpp:168: internal error: Segmentation fault
> ...

 

prova magari a mettere march=athlon o ancora piu' sicuro -march=i686. Se ti dovesse dare ancora segfault puoi provare a fare un bel memtest  :Smile: 

----------

## cerri

Sembra quasi un problema di memoria...

Quanta memoria hai?

Altrimenti credo che sia un problema di overclock.

CMQ puoi provare:

```
CFLAGS="-march=athlon-xp -O2 -pipe" 
```

anche se non credo che tu possa risolvere.

----------

## dnix

ho 256 mega di RAM e 100 di swap, mentre il processore e' stabile, ho ricompilato le gcc  :Smile:  e' gia' da un po' che ho lo stesso problema e solo con versioni di qt-3

----------

## Josuke

hai provato a compilare le qt3 a mano senza l'emerge?

----------

## Gavrila

 *dnix wrote:*   

> ho 256 mega di RAM e 100 di swap, mentre il processore e' stabile, ho ricompilato le gcc  e' gia' da un po' che ho lo stesso problema e solo con versioni di qt-3

 

si ma magari qualche banco e' diifettoso... prova memtest

----------

## dnix

compilando senza gli ebuild mi da un errore interno di compilazione:

Internal compiler error in make_decl_one_only, at varasm.c:5222

e comunque sempre in punt idifferenti

----------

## Gavrila

 *dnix wrote:*   

> compilando senza gli ebuild mi da un errore interno di compilazione:
> 
> Internal compiler error in make_decl_one_only, at varasm.c:5222
> 
> e comunque sempre in punt idifferenti

 

e' proprio questo comportamento random a farmi pensare a un banco di memoria difettoso. Togliti lo sfizio e prova memtest.

----------

## dnix

e per effettuare memtest? non ho mai provato...

----------

## Gavrila

 *dnix wrote:*   

> e per effettuare memtest? non ho mai provato...

 

non so se esiste nel portage (emerge -s memtest). Altrimenti fai una velocissima ricerca su  :Smile: 

ah importante e' abilitare TUTTI i test  :Wink: 

----------

## cerri

```
# emerge memtest86
```

----------

## bsolar

 *cerri wrote:*   

> 
> 
> ```
> # emerge memtest86
> ```
> ...

 

È anche disponibile nel livecd.

----------

## dnix

e per poi usarlo ed avere risultati leggibili?

----------

## Gavrila

 *dnix wrote:*   

> e per poi usarlo ed avere risultati leggibili?

 

quando parte (devi fartici un dischetto) fai partire tutti i test e lui ti dice quanti errori fa' se li fa  :Smile: 

----------

## dnix

memtest dice che non ci sono errori e l'ho eseguito 2 volte  :Sad: 

----------

## Gavrila

 *dnix wrote:*   

> memtest dice che non ci sono errori e l'ho eseguito 2 volte 

 

se l'hai fatto con TUTTI i test (di default non sono tutti lo devi selezionare tu), allora ti invito a provare a fare come ti avevo detto quache post piu sopra, cambiando -O3 con -O2, e march=athlon o se non va nemmeno cosi' -march=i686  :Smile: 

----------

## bsolar

Sicuro che non è un problema di surriscaldamento? cpuburn?

----------

## cerri

O anche un gioco sotto windows...

----------

## Gavrila

 *cerri wrote:*   

> O anche un gioco sotto windows...

 

??????   :Shocked: 

----------

## cerri

Dopo il rendering, i giochi 3d sotto windows sono una delle cose piu' pesanti che ci sono.

Mi ricordo che un mio amico rivenditore, che vendeva anche materiale per overclock, provava i sistemi con Unreal Tournament....  :Wink: 

----------

## bsolar

 *cerri wrote:*   

> Dopo il rendering, i giochi 3d sotto windows sono una delle cose piu' pesanti che ci sono.

 

Non credo spremano il processore incessantemente e difficilmente lo spremono al livello di gcc (che credo sia l'applicazione che lo sfrutta in maniera più estesa dopo cpuburn, per questo molti problemi latenti vegnono fuori da compilazioni prolungate).

Per fare dei test potrebbe interessare questo link.

----------

## cerri

(sotto windows) ti posso garantire che ho visto morire macchine sotto Unreal e non sotto i vari programmini di burn, perche' un gioco ha il vantaggio di stressare tutti i componenti (sk video, cpu, memorie, ctrl, ecc), ovviamente con i dovuti settaggi (sotto unreal e sotto quake ci sono delle modalita' molto utili a questi scopi)....  :Wink: 

Che poi gcc sia stressante, quello e' fuori dubbio   :Razz: 

----------

## bsolar

 *cerri wrote:*   

> (sotto windows) ti posso garantire che ho visto morire macchine sotto Unreal e non sotto i vari programmini di burn, perche' un gioco ha il vantaggio di stressare tutti i componenti (sk video, cpu, memorie, ctrl, ecc)

 

Ho visto macchine sopravvissute senza problemi a sessioni interminabili di gioco morire dopo poche ore di compilazione. Il problema di un videogioco è che bisognerebbe impostarlo per non soffrire di colli di bottiglia che altrimenti non consentirebbero alla CPU di lavorare senza alcuna interruzione (nemmeno infinitesima). CMQ va bene come test superficiale, solo non credo possa arrivare al livello di stress che la compilazione a catena del kernel (per non parlare di cpuburn ovviamente) può raggiungere.

Naturalmente sto parlando di test della CPU, poi se vuoi testare la scheda video è un altro discorso.

Tra l'altro è un'altro svantaggio del tuo metodo perché ti ritroveresti a non sapere esattamente qual'è la componente problematica e dovresti fare altri test mirati...

----------

## dnix

fatto sta che ho compilato Xfree, dopo mozilla e infine latex e il tutto senza problemi ed in solo... 9 ore! quindi 30 min di qt mi sembrano nulla! in piu' ho provato a compilarlo senza ebuild, quindi senza settaggi di compilazione, dando solo ./configure make e si pianta lo stesso.

----------

## Gavrila

 *bsolar wrote:*   

>  *cerri wrote:*   (sotto windows) ti posso garantire che ho visto morire macchine sotto Unreal e non sotto i vari programmini di burn, perche' un gioco ha il vantaggio di stressare tutti i componenti (sk video, cpu, memorie, ctrl, ecc) 
> 
> Ho visto macchine sopravvissute senza problemi a sessioni interminabili di gioco morire dopo poche ore di compilazione. Il problema di un videogioco è che bisognerebbe impostarlo per non soffrire di colli di bottiglia che altrimenti non consentirebbero alla CPU di lavorare senza alcuna interruzione (nemmeno infinitesima). CMQ va bene come test superficiale, solo non credo possa arrivare al livello di stress che la compilazione a catena del kernel (per non parlare di cpuburn ovviamente) può raggiungere.
> 
> Naturalmente sto parlando di test della CPU, poi se vuoi testare la scheda video è un altro discorso.
> ...

 

----------

## Gavrila

 *dnix wrote:*   

> fatto sta che ho compilato Xfree, dopo mozilla e infine latex e il tutto senza problemi ed in solo... 9 ore! quindi 30 min di qt mi sembrano nulla! in piu' ho provato a compilarlo senza ebuild, quindi senza settaggi di compilazione, dando solo ./configure make e si pianta lo stesso.

 

Sei sicuro che facendo a mano ./configure e make, il sistema ignori tutti le flag di gcc del make.conf? In caso di risposta negativa prova a cambiare quelle.

Cmq prova anche a fare un emerge sync, magari l'ebuild era buggata e l'hanno risolto, poi guarda su bugs.gentoo.org se e' segnalato qualche bug per quella ebuild.

----------

## dnix

era un problema di QT. compilando le 3.2 beta si e' risolto tutto e ora sto compilando il pacchetto gnome per intero   :Wink: 

----------

