2010-11-11 22 views
10

Je viens d'essayer les dernières versions de llvm et clunk trunk. Ils ont compilé sans un seul avertissement hors de la boîte, mais j'ai du mal à relier un exemple de bonjour monde. Mon code estproblème de lien clang

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

Si je compile en utilisant

clang test.c 

je reçois l'erreur suivante

/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) 

L'utilisation -v montre que le gnou ld est invoquée comme

"/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 

Mais j'ai le fichier objet crt1.o!

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

Ce qui fonctionne aussi est

clang -c test.c 
gcc test.o 

et bien sûr

gcc test.c 

Ce que je encore essayé:

$ 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 

J'ai aussi essayé de copier le fichier dans crt1.o le répertoire actuel. Cela a semblé fonctionner. Eh bien, il n'a pas compilé, car après cela crti.o manquait.

Ma distribution est Ubuntu.

Eh bien, je ne sais pas vraiment quoi essayer ensuite. Je ne vois pas comment je pourrais corriger le clang et je n'ai pas d'idée sur la façon d'injecter le chemin nécessaire dans l'invocation ld. Des idées?

+0

ne me reste qu'une brève description de -Xlinker dans la page de mon clang mais n'est pas censé être -Xlinker passé deux fois pour les options avec un argument? Voici ce que disent les pages de manuel de gcc pour Xlinker. – anddam

Répondre

3

semble être la version clang qui ne peut pas détecter la version Linux de l'hôte et la version gcc ..

Ce code clang qui doit ajouter le chemin vers le 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"))); 

et la GetFilePath va essayer de rechercher les fichiers demandés dans getFilePaths() liste de ToolChain en cours (fichier clang/lib/Driver/ToolChains.cpp). S'il ne peut pas trouver un fichier, il retournera le nom inchangé.

S'il vous plaît, donnez-moi la version de votre ubuntu (uname -a, cat /etc/lsb-release), sortie exacte (svn numéro de révision) de clang et LLVM, et gcc -v sortie

+2

Curieusement, l'implémentation de cette fonction diffère de celle que vous avez citée ... Cependant, en ajoutant Paths.push_back ("/ usr/lib"); Paths.push_back ("/ usr/lib/gcc/i486-linux-gnu/4,4/"); a fait l'affaire. Si j'interprète correctement le code, alors il ne regarde que dans/usr/lib quand/usr/lib64 n'existe pas. Cependant ce répertoire existe sur mon système – Ben04

+0

il y avait une citation très ancienne. maintenant je reçois le http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ et je peux vérifier le code pour votre combinaison de clang rev, ubuntu et gcc version – osgx

+0

Code de 'GetFilePath()' trys pour ouvrir un fichier demandé (crt1.o) dans chaque répertoire de la liste 'getFilePaths()'. Il s'arrêtera s'il y a un fichier quelque part ou il retournera le nom du fichier sans le chemin – osgx

1

Cette HACK horrible "fixe" compilation/liaison avec clang 3.0 (r142716) sur Ubuntu 11.10 (x86)

Dans le fichier inclus à partir de /usr/include/stdio.h:28:
/usr/include/features.h:323:10: erreur fatale: « bits/predefs. h fichier introuvable

/usr/bin/ld: impossible de trouver crt1.o: No such fichier ou répertoire
/usr/bin/ld: impossible de trouver crti.o: Aucun fichier ou répertoire

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

Ce patch n'est plus nécessaire depuis r143344, r143345, r143346. Le problème devrait être résolu maintenant. voir http://llvm.org/bugs/show_bug.cgi?id=11223 – Peter

0

course:

clang -v 

Dans mon exemple de sortie est:

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

Exécutez la commande suivante en tant que root d'utiliser la cible pour créer le répertoire manquant comme un lien:

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

Sur la version la plus récente (3.5), ce genre de problème a de nouveau surgi pour tous ceux qui font une build en utilisant l'option de configuration --with-gcc-toolchain sur un système avec une librairie pré-gcc 4.7 libstdC++ installée.

Vous verrez en deux saveurs:

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

... et ne pas être sur le point de trouver les différents fichiers crt.

Dans les deux cas, ce qui suit vous permet de contourner le problème jusqu'à ce qu'il se fixe:

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