# ERRORE: "C compiler cannot create executables"

## rete27

Ciao 

premetto subito che ho ancora poca esperienza ma le cose cambiano...

Venendo a noi ho quando cerco di fare qualsiasi cosa con emerge o più in generale con il gcc mi appare un errore del tipo 

```
 C compiler cannot create executables
```

Ho provato a vedere e di sistemare le CFLAGS come dice la wiki di gentoo ma non si risolve nulla...ho provato a fare il fix_libtool_files.sh ma nulla...

la versione di gcc installata è la 4.1.2 e del gcc-config è 1.3.16

grazie a tutti (in anticipo   :Wink:  )

----------

## Ic3M4n

puoi postare il make.conf che i fatti sono meglio delle parole  :Wink: 

----------

## crisandbea

una ricerchina nel forum non farebbe mai male 

https://forums.gentoo.org/viewtopic-t-27486-postdays-0-postorder-asc-start-150.html

ciao

----------

## djinnZ

con quali CFLAGS o LDFLAGS lo hai compilato l'utima volta? Prima di postare il make.conf controlla se non hai scritto male qualche parametro.

----------

## rete27

 *Ic3M4n wrote:*   

> puoi postare il make.conf che i fatti sono meglio delle parole 

 

allora 

```

VIDEO_CARDS="radeon vesa"

INPUT_DEVICES="keyboard mouse"

LINGUAS="it en"

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"

CXXFLAGS="${CFLAGS}"

LDFLAGS="-Wl,-z,now,-O1,--hash-style=gnu"

PORTAGE_TMPDIR=/var/tmp

PORTDIR=/usr/portage

DISTDIR=${PORTDIR}/distfiles

PKGDIR=${PORTDIR}/packages

PORT_LOGDIR=/var/log/portage

PORTDIR_OVERLAY=/usr/local/portage

FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp \${URI} -P \${DISTDIR}"

RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp \${URI} -P \${DISTDIR}"

GENTOO_MIRRORS="ftp://mirror.switch.ch/mirror/gentoo/ http://mirror.switch.ch/ftp/mirror/gentoo/ http://ds.thn.htu.se/linux/gentoo http://ftp.du.se/pub/os/gentoo http://linuv.uv.es/mirror/gentoo/"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

MAKEOPTS="-j2"

PORTAGE_NICENESS=10

AUTOCLEAN="yes"

```

eccolo...penso che sia configurato giusto

per quanto riguarda l' ultima compilazione come CFLAGS avevo anche -mmmx e -msse

----------

## djinnZ

LDFLAGS purtroppo è concepito come parametro gcc e viene passato al gcc e non come parametro ld (pensavo anche io il contrario) quindi ="-Wl,-O1 -Wl,--hash-style=gnu ..." se non erro.

----------

## rete27

cambito la LDFLAGS ma l'errore riamane ed è lo stesso...

```
checking for C compiler default output file name... configure: error: C compiler cannot create executables

```

----------

## Ic3M4n

commenta le LDFLAGS così vediamo se l'errore è lì dentro. Almeno ci concentriamo, ad esclusione su ogni singolo parametro.

----------

## .:deadhead:.

hai un ricordo preciso di quando sia stata l'ultima volta che ti si sia compilato qualcosa senza problemi?

ti suggerirei cmq pure io di commentare LDFLAG almeno al momento per risolvere la faccenda....

----------

## rete27

coommentendo la LDFLAGS il compilatore lavora senza dare noie infatti  *Quote:*   

> 
> 
> checking for C compiler default output file name... a.out
> 
> checking whether the C compiler works... yes
> ...

 

ora penso che il problema sia solo di configurazione delle flag del ld giusto ?

----------

## .:deadhead:.

 *rete27 wrote:*   

> ora penso che il problema sia solo di configurazione delle flag del ld giusto ?

 

Già... La cosa migliore sarebbe ora che tu ricompilassi tutti i pacchetti del system, così da garantirti un ambiente di compilazione sano... gli altri pacchetti poi verranno compilati via via che saranno aggiornati, ma almeno avrai la certezza d partir da solide basi...

----------

## rete27

 *.:deadhead:. wrote:*   

> Già... La cosa migliore sarebbe ora che tu ricompilassi tutti i pacchetti del system, così da garantirti un ambiente di compilazione sano... gli altri pacchetti poi verranno compilati via via che saranno aggiornati, ma almeno avrai la certezza d partir da solide basi...

 

ricompilo il tutto lasciando commentato LDFALGS ? non sraebbe meglio fare dei tentativi per cercare di impostare dei paremetri ?

----------

## crisandbea

 *rete27 wrote:*   

>  *.:deadhead:. wrote:*   Già... La cosa migliore sarebbe ora che tu ricompilassi tutti i pacchetti del system, così da garantirti un ambiente di compilazione sano... gli altri pacchetti poi verranno compilati via via che saranno aggiornati, ma almeno avrai la certezza d partir da solide basi... 
> 
> ricompilo il tutto lasciando commentato LDFALGS ? non sraebbe meglio fare dei tentativi per cercare di impostare dei paremetri ?

 

hai già guardato qui

ciao

----------

## .:chrome:.

risolto il mistero.

quella macchina usava l'hash-style GNU, ma in un aggiornamento del sistema Ã¨ stato fatto accidentalmente un downgrade di binutils alla versione 2.17, quando attualmente deve essere usata almeno la versione 2.17.50.0.12 per poter usare l'hash-style

corretto e sistemato

----------

## djinnZ

ora me ne sono accorto pure io che il sistema mi ha fatto il downgrade dalla 2.17 (che non ho certo installato ~86) alla 2.16 che è l'unica stabile. Qualcuno ha maggiori info?

perchè cmake non compila più...

----------

## rete27

se ti va di fidarti di un noob emergi la binutils 2.17.50.0.12 e poi come LDFLAGS (grazie a .:chrome:.)

```

LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--hash-style=gnu -s"

```

ora a me funziona tutto bene...

----------

## .:chrome:.

 *djinnZ wrote:*   

> ora me ne sono accorto pure io che il sistema mi ha fatto il downgrade dalla 2.17 (che non ho certo installato ~86) alla 2.16 che è l'unica stabile. Qualcuno ha maggiori info?
> 
> perchè cmake non compila più...

 

perché con quella versione di binutils, il valore "-Wl, --hash-style=gnu" non è più riconosciuto come un parametro valido per il linker, quindi la fase di compilazione fallisce.

il downgrade è stato fatto perché è cambiato il formato di package.keywords, come descritto nel post del 14 giugno sul blog di Marius Mauch

----------

## djinnZ

@rete27 non è perchè sei noob (esser nuovo sul forum non implica essere nuovo a linux) ma sono su hardened quindi prendo con una certa preoccupazione questi "incidenti".

@.:chrome:.

in che senso perchè è cambiato il package.keywords? Non riesco a capire il nesso, o è un mezzo bug?!

Cambiare binutils non è uno scherzo con l'hardening e l'ottimizzazione che uso.

----------

## .:chrome:.

 *djinnZ wrote:*   

> in che senso perchè è cambiato il package.keywords? Non riesco a capire il nesso, o è un mezzo bug?!

 

è cambiato il formato per includere i pacchetti con "missing" keyword, come spiegato in quel blog

----------

## drizztbsd

 *rete27 wrote:*   

> se ti va di fidarti di un noob emergi la binutils 2.17.50.0.12 e poi come LDFLAGS (grazie a .:chrome:.)
> 
> ```
> 
> LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--hash-style=gnu -s"
> ...

 

 :Crying or Very sad: 

--enable-new-dtags c'è di default da una cifra di binutils quindi è inutile settarlo (e basta rippare le LDFLAGS da quel thread inutile)

-s è DANNOSO, non usatelo per nessun motivo

--sort-common non è stabile, alcuni pacchetti non vanno.

Io consiglio le solite

```
LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
```

----------

## djinnZ

sarï¿½ il caldo bestiale che mi rende piï¿½ idiota del solito ma continuo a non capire il nesso tra rimozione del "-*" ed il downgrade delle binutils stabili a 2.16.

----------

## rete27

@djinnZ

l'attula riga in package.keywords per le binutils è

```

=sys-devel/binutils-2.17.50.0.12 -*
```

prova a sistemare le LDFLAG come ho postato e poi sistema come sopre il package.keywords e prova a vedere... a mio avviso dovrebbe funzionare tutto correttamente...  :Wink: 

----------

## djinnZ

Non ci siamo capiti ancora. Ho installato il sistema stabile e solo pochissimi pacchetti (ntfs3g, beryl e qualche programma di utilità in praticaq) sono ~x86. Eppure mi ritrovo binutils 2.17 (non 2.17.xxx 2.17 e basta) installato e non riesco a capire perchè, evidentemente, è stato prima marcato stabile e poi rimarcato instabile su hardened.

Od uno straccio di ragione per considerare instabili le binutils >2.17.50 o quale delle successive è più abbordabile visto che cmake (per il momento) con le 2.16 non vuol saperne di compilare.

Lo so che è un pacchetto slottato e ne posso avere più versioni ma dato che sono deficiente ed ogni volta che faccio uno switch di compilatore o che sia mi scordo sistematicamente di rimettere le cose a posto vorrei garantirmi dalla mia distrazione.

----------

## .:chrome:.

la 2.17 è la versione stabile: http://packages.gentoo.org/packages/?category=sys-devel;name=binutils

per usare --hash-style=gnu devi avere almeno la 2.17.50.0.12, che è in keyword "missing"

----------

## drizztbsd

 *rete27 wrote:*   

> @djinnZ
> 
> l'attula riga in package.keywords per le binutils è
> 
> ```
> ...

 

```
=sys-devel/binutils-2.17.50* **
```

 in package.keywords

----------

## djinnZ

certe volte mi domando se non vi divertite alle mie spalle facendo finta di non capire...

In ogni caso mi rispondo da solo (almeno credo di aver trovato) su hardened dovrebbe essere disabilitatata come stabile per via di questo bug mentre .:chrome:. mi conferma se su x86 "normale" è la stabile.

Su hardened a fare i pignoli non è molto serio avere le binutils bucate ma dato che mi interessa che il sistema sia sicuro solo a runtime e non nella compilazione mi arrischio.

----------

