# distcc -fPIC

## forrestfunk81

Hallo,

ich habe ein DistCC Problem. Fast alle Builds werden abgebrochen mit folgendem Fehler (hier am Beispiel von libcap-ng):

```
libtool: link: x86_64-pc-linux-gnu-gcc -W -Wall -Wshadow -Wformat -Wundef -D_GNU_SOURCE -march=amdfam10 -O2 -pipe -mno-3dnow -mcx16 -mpopcnt -msse3 -msse4a -mmmx -Wl,-O1 -o .libs/pscap pscap.o  -Wl,--as-needed -L../src /var/tmp/portage/sys-libs/libcap-ng-0.7.3/work/libcap-ng-0.7.3/src/.libs/libcap-ng.so

/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: filecap.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC

filecap.o: error adding symbols: Bad value

collect2: error: ld returned 1 exit status

distcc[15904] ERROR: compile (null) on localhost failed

/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: pscap.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

pscap.o: error adding symbols: Bad value

collect2: error: ld returned 1 exit status

```

Wenn ich global (oder über package.env je Package) -fPIC für CFLAGS und CXXFLAGS setze, laufen die Builds durch. Dabei wird doch laut configure Meldung erkannt, dass -fPIC möglich ist.

```
checking if x86_64-pc-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no

checking for x86_64-pc-linux-gnu-gcc option to produce PIC... -fPIC -DPIC

checking if x86_64-pc-linux-gnu-gcc PIC flag -fPIC -DPIC works... yes

checking if x86_64-pc-linux-gnu-gcc static flag -static works... yes

checking if x86_64-pc-linux-gnu-gcc supports -c -o file.o... yes

checking if x86_64-pc-linux-gnu-gcc supports -c -o file.o... (cached) yes

checking whether the x86_64-pc-linux-gnu-gcc linker (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries... yes

```

Laut der Gentoo Doku ist es aber nicht empfehlenswert -fPIC global zu aktivieren:

 *Quote:*   

>  In this case, globally adding -fPIC to C[XX]FLAGS resolves the issue, although this practice is discouraged because the executables end up being PIC-enabled, too. 

 

Weitere Infos:

kein Cross Compile, beide x86_64 und GCC Versionen sind auf beiden Systemen gleich. Der Fehler tritt auf, egal ob mit DistCC Pump Mode oder ohne. Der schnelle Rechner kompiliert fehlerfrei für sich selbst, ohne DistCC. Der langsame Rechner soll DistCC benutzen. Der langsame Rechner ist hardened, der schnelle nicht. Beide Rechner dienen außerdem als Cross Compile Hosts für meinen Raspberry Pi, was auch problemlos funktioniert.

Liegt die Ursache des Problems darin, dass der Client hardened ist? Welche Auswirkungen hat es, wenn ich -fPIC global aktiviere und damit auch die Executables PIC-enabled sind?

----------

## chaoscommander

Ich habe genau das gleiche Problem. Interessanterweise hat distcc in der Konfiguration schon mal funktioniert, und ich erinnere mich nicht, seither die Einstellungen geändert zu haben (außer distcc zu deaktivieren, weil immer wieder einzelne Pakte versagten).

edit: mit -fPIC funktioniert es jedenfalls. Wie ich das verstehe, bewirkt das ein kleines bisschen Overhead bei der Ausführung der PIC-enabled Software, aber soll laut Wikipedia auf modernen Prozessoren kaum auffallen. Ich probier das jetzt so...

----------

## forrestfunk81

Ich hatte in den letzten Monaten DistCC für diesen Rechner deaktiviert. 

Laut GCC Doku bedeutet PIC (position-independent code), dass sich der kompilierte Code nicht an einer konstanten Speicheradresse befindet, sondern dynamisch geladen wird. Es gibt ja einige Hardened Kernel Optionen, die genau das forcieren. Wie Kernel und User Space Software da zusammenarbeiten weiß ich allerdings nicht.

Jetzt muss ich mal GCC updaten und schauen, ob das Problem immer noch auftritt. Wenn ja, werde ich -fPIC auch global aktivieren.

----------

