2010-11-11 30 views
10

Acabo de probar las últimas versiones de llvm y clang trunk. Compilaron sin una sola advertencia, pero estoy teniendo problemas para vincular un ejemplo de Hello World. Mi código esproblema de vinculador de clang

#include <stdio.h> 
int main(){ 
    printf("hello\n"); 
} 

Si puedo compilar usando

clang test.c 

me sale el siguiente error

/usr/bin/ld: crt1.o: No such file: No such file or directory 
clang: error: linker command failed with exit code 1 (use -v to see invocation) 

Usando -v muestra que la GNU ld es invocada como

"/usr/bin/ld" --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o a.out crt1.o crti.o crtbegin.o -L -L/../../.. /tmp/cc-0XJTsG.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o crtn.o 

¡Pero tengo el archivo de objeto crt1.o!

$ locate crt1.o 
/usr/lib/Mcrt1.o 
/usr/lib/Scrt1.o 
/usr/lib/crt1.o 
/usr/lib/gcrt1.o 

Lo que también funciona es

clang -c test.c 
gcc test.o 

y por supuesto

gcc test.c 

Lo que más intentado:

$ clang -Xlinker "-L /usr/lib" test.c 
/usr/bin/ld: crt1.o: No such file: No such file or directory 
clang: error: linker command failed with exit code 1 (use -v to see invocation) 
$ clang -Xlinker "-L /usr/lib" test.c -v 
"/usr/bin/ld" --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o a.out crt1.o crti.o crtbegin.o -L -L/../../.. -L /usr/lib /tmp/cc-YsI9ES.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o 

También intenté copiar el archivo en crt1.o el directorio actual. Eso pareció funcionar. Bueno, no compiló porque después de eso crti.o faltaba.

Mi distribución es Ubuntu.

Bueno, realmente no sé qué probar a continuación. No veo cómo podría solucionar el clang ni tengo una idea sobre cómo inyectar el camino necesario en la invocación de ld. ¿Algunas ideas?

+0

que sólo tienen una breve descripción de -Xlinker en la página de mi sonido metálico, pero no se supone que es -Xlinker pasado dos veces por opciones con argumentos? Esto es lo que las páginas man de gcc dicen para -Xlinker. – anddam

Respuesta

3

parece ser la versión ruido metálico que no se puede detectar versión de Linux y la versión de gcc de anfitrión ..

Este código de sonido metálico que debe agregar la ruta al CRT *: llvm›tools›clang›lib›Driver›Tools.cpp

CmdArgs.push_back(Args.MakeArgString(getToolChain().GetFilePath(C, "crt1.o"))); 
    CmdArgs.push_back(Args.MakeArgString(getToolChain().GetFilePath(C, "crti.o"))); 
    CmdArgs.push_back(Args.MakeArgString(getToolChain().GetFilePath(C, "crtbegin.o"))); 

y la GetFilePath intentará buscar archivos solicitados en la lista getFilePaths() del ToolChain actual (archivo clang/lib/Driver/ToolChains.cpp). Si no puede encontrar un archivo, devolverá el nombre sin cambios.

Por favor, dame versión de sus ubuntu (uname -a, cat /etc/lsb-release), exacta de lanzamiento (SVN número de revisión) del sonido metálico y llvm y gcc -v salida

+2

Curiosamente la implementación de esa función que tengo difiere de la que usted citó ... Sin embargo, agregando Paths.push_back ("/ usr/lib"); Paths.push_back ("/ usr/lib/gcc/i486-linux-gnu/4.4/"); Hizo el truco. Si interpreto correctamente el código, entonces solo se ve en/usr/lib cuando/usr/lib64 no existe. Sin embargo, ese directorio existe en mi sistema – Ben04

+0

, había una cita muy antigua. ahora obtengo el http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ y puedo verificar el código de tu combinación de clang rev, ubuntu y gcc versión – osgx

+0

Código de 'GetFilePath()' trys para abrir un archivo solicitado (crt1.o) en cada directorio en la lista 'getFilePaths()'. Se detendrá si hay un archivo en alguna parte o devolverá el nombre de archivo sin la ruta – osgx

1

este horrible Hack "correcciones" compilar/enlazar con sonido metálico 3.0 (r142716) en Ubuntu 11.10 (x86)

en archivo incluido desde /usr/include/stdio.h:28:
/usr/include/features.h:323:10: error grave: 'bits/predefs. h 'archivo no encontrado

/usr/bin/ld: no se puede encontrar crt1.o: No such archivo o directorio
/usr/bin/ld: no se puede encontrar crti.O: No existe el fichero o directorio

diff --git a/lib/Driver/Driver.cpp b/lib/Driver/Driver.cpp 
index 75300b5..3e2be30 100644 
--- a/lib/Driver/Driver.cpp 
+++ b/lib/Driver/Driver.cpp 
@@ -241,6 +241,7 @@ Compilation *Driver::BuildCompilation(ArrayRef<const char *> ArgList) { 
    // FIXME: Handle environment options which affect driver behavior, somewhere 
    // (client?). GCC_EXEC_PREFIX, LIBRARY_PATH, LPATH, CC_PRINT_OPTIONS. 

+ PrefixDirs.push_back("/usr/lib/i386-linux-gnu"); 
    if (char *env = ::getenv("COMPILER_PATH")) { 
    StringRef CompilerPath = env; 
    while (!CompilerPath.empty()) { 
diff --git a/lib/Frontend/InitHeaderSearch.cpp b/lib/Frontend/InitHeaderSearch.cpp 
index b066e71..c6ffee8 100644 
--- a/lib/Frontend/InitHeaderSearch.cpp 
+++ b/lib/Frontend/InitHeaderSearch.cpp 
@@ -562,10 +562,12 @@ void InitHeaderSearch::AddDefaultCIncludePaths(const llvm::Triple &triple, 
     AddPath("/usr/include/x86_64-linux-gnu", System, false, false, false); 
     AddPath("/usr/include/i686-linux-gnu/64", System, false, false, false); 
     AddPath("/usr/include/i486-linux-gnu/64", System, false, false, false); 
+  AddPath("/usr/include/i386-linux-gnu/64", System, false, false, false); 
    } else if (triple.getArch() == llvm::Triple::x86) { 
     AddPath("/usr/include/x86_64-linux-gnu/32", System, false, false, false); 
     AddPath("/usr/include/i686-linux-gnu", System, false, false, false); 
     AddPath("/usr/include/i486-linux-gnu", System, false, false, false); 
+  AddPath("/usr/include/i386-linux-gnu", System, false, false, false); 
    } else if (triple.getArch() == llvm::Triple::arm) { 
     AddPath("/usr/include/arm-linux-gnueabi", System, false, false, false); 
    } 
+1

Este parche ya no es necesario desde r143344, r143345, r143346. El problema debería solucionarse ahora. ver http://llvm.org/bugs/show_bug.cgi?id=11223 – Peter

0

de ejecución:

clang -v 

En mi ejemplo de salida es:

clang version 3.0 (tags/RELEASE_30/final) 
Target: armv7l-unknown-linux-gnueabi 
Thread model: posix 

ejecute el siguiente como root para usar el objetivo de crear el directorio que falten como un enlace:

ln -s /lib/arm-linux-gnueabi /lib/armv7l-unknown-linux-gnueabi 
ln -s /usr/lib/arm-linux-gnueabi /usr/lib/armv7l-unknown-linux-gnueabi 
ldconfig 
1

En el lanzamiento más reciente (3.5), este tipo de problema ha surgido nuevamente para cualquiera que realice una compilación utilizando la opción de configuración --with-gcc-toolchain en un sistema con una biblioteca pre-gcc 4.7 libstdC++ instalada.

Lo verá en dos sabores:

echo '#include <string>' | clang++ -xc++ - 
<stdin>:1:10: fatal error: 'string' file not found 
#include <string> 
     ^
1 error generated. 

... así como no estar a punto de descubrir los diversos archivos CRT.

En ambos casos, el siguiente le permite solucionar el problema hasta que se fija:

printf '#include <string>\nint main(int argc, char *argv[]) { return 0; }' > /tmp/blah.cc 
# Fixes issue not finding C++ headers; note that it must be gcc >= 4.7 
clang++ --gcc-toolchain=/path/to/gcc/install -c -o /tmp/blah.o /tmp/blah.cc 
# Fixes the link error 
clang++ --gcc-toolchain=/path/to/gcc/install /tmp/blah.o /tmp/blah