Errore di compilazione Waterslide


#1

Salve,
in locale riesco a compilare ed eseguire correttamente il programma.
Sul server online ottengo questo errore di compilazione.
Grazie anticipatamente aiuto e suggerimenti.

/tmp/ccggkTRj.o: In function `_GLOBAL__sub_I_adiacenze':
waterslide.cpp:(.text.startup+0x335): relocation truncated to fit: R_X86_64_32 against `.bss'
waterslide.cpp:(.text.startup+0x344): relocation truncated to fit: R_X86_64_32 against `.bss'
/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a(eh_alloc.o): In function `(anonymous namespace)::pool::free(void*) [clone .constprop.2]':
(.text._ZN12_GLOBAL__N_14pool4freeEPv.constprop.2+0x18): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZN12_GLOBAL__N_114emergency_poolE'
/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a(eh_alloc.o): In function `(anonymous namespace)::pool::free(void*) [clone .constprop.2]':
(.text._ZN12_GLOBAL__N_14pool4freeEPv.constprop.2+0x2c): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZN12_GLOBAL__N_114emergency_poolE'
/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a(eh_alloc.o): In function `(anonymous namespace)::pool::free(void*) [clone .constprop.2]':
(.text._ZN12_GLOBAL__N_14pool4freeEPv.constprop.2+0x9f): relocation truncated

#2

Probabilmente stai tentando di allocare troppa memoria come una matrice 100k * 100k. Senza vedere il code non saprei dirti di più.


#3

Si, ma mi aspettavo di avere un errore a run-time, non in compilazione…


#4

Problema curioso…

In effetti il codice prevede un’allocazione di circa 40 GB nella sezione .bss (Wikipedia), che in buona sostanza è la parte dell’eseguibile in cui il compilatore mette le variabili allocate staticamente.

Gli indirizzi delle istruzioni assembly (sezione .text, che si trova dopo la .bss nel file) a questo punto superano i 32 bit e il linker - che per ragioni di velocità usa indirizzi di default a 32 bit - fallisce il processo di rilocazione, producendo l’errore mostrato sopra.

Una semplice prova usando l’opzione -S del compilatore conferma che la compilazione in senso stretto si conclude correttamente producendo il sorgente assembler. È proprio la fase successiva, ad opera del linker, a fallire.

Per chi volesse approfondire: uno dei vari siti che analizzano la questione


#5

Grazie, interessante analisi del problema.

In particolare nell’articolo si cita l’opzione -mmodel di gcc…

A tal proposito, è possibile sapere la linea di compilazione/linking usata sulla piattaforma in modo che possa replicarla in locale?


#6

Certamente, anche se non usiamo alcun parametro esoterico. Ne ho parlato poco tempo fa in questo thread.


#7

Ho provato ad usare il comando citato nel thread che ha fallito con il seguente messaggio di errore:

    $ g++ -DEVAL -std=gnu++11 -O2 -pipe -static -s waterpark.cpp 
    ld: warning: option -s is obsolete and being ignored
    ld: library not found for -lcrt0.o
    clang: error: linker command failed with exit code 1 (use -v to see invocation)

Questa è la versione di gcc installata sulla mia macchina:

$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

#8

Mac OS X non supporta binari linkati staticamente (fonte Apple).

Per ottenere il binario si può rimuovere il parametro -static (naturalmente questo produrrà un eseguibile linkato dinamicamente).


#9

Senza il parametro -static il comando produce correttamente l’eseguibile che funziona normalmente sulla mia macchina (iMac Intel Core i5 con 8GB RAM).


#10

… perché ragionevolmente l’eseguibile starà usando indirizzi a 64 bit. Questo dovrebbe essere dovuto al fatto che g++ aggiunge il parametro -pie come opzione del linker automaticamente quando non viene specificato -static.

Si potrebbe fare una prova ulteriore forzando la compilazione con -no-pie.


#11

Questo è il risultato:

$ g++ -DEVAL -std=gnu++11 -O2 -pipe -no-pie waterpark.cpp 
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]

#12

:sweat:

Quel sistema impiega clang come alternativa al compilatore GNU, questo spiega le differenze. Purtroppo non ho sistemi Apple su cui sperimentare.

L’altra strada che mi viene in mente è installare il vero compilatore GNU (non clang!) e provare con quello. Non mi incaponirei più di tanto comunque: anche se può essere interessante e didattico riprodurre l’errore in locale, la diagnosi di qualche post credo sia già abbastanza esauriente in merito al problema.


#13

Grazie, non mi ero reso conto che il compilatore installato non era il vero gcc, ma LLVM+clang.