2010-11-11 17 views
10

Właśnie wypróbowałem najnowsze wersje llvm i clang trunk. Skompilowano je bez pojedynczego ostrzeżenia po wyjęciu z pudełka, ale mam problem z połączeniem przykładu Witaj świecie. Mój kod jestProblem łącznika klinowego

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

Jeśli mogę skompilować za pomocą

clang test.c 

pojawia się następujący błąd

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

Korzystanie -v pokazuje, że ld gnu jest wywoływana jako

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

Ale mam plik obiektów crt1.o!

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

Co działa również jest

clang -c test.c 
gcc test.o 

i oczywiście

gcc test.c 

Co dalej próbowałem:

$ 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 

Próbowałem również skopiowanie pliku do crt1.o bieżący katalog. To wydawało się działać. Cóż, nie skompilował, ponieważ po tym crti.o zaginął.

Moja dystrybucja to Ubuntu.

Cóż, nie wiem, jak spróbować. Nie widzę, jak mógłbym naprawić klang, ani nie mam pomysłu na wstrzyknięcie wymaganej ścieżki w inwokacji ld. Jakieś pomysły?

+0

Mam tylko krótki opis -Xlinker w stronę mojego dzyń, ale nie jest -Xlinker miało być przeszedł dwa razy dla opcji z argumentami? Oto, co mówią strony man gcc dla -Xlinker. – anddam

Odpowiedz

3

Wydaje się być clang wersję, która nie może wykryć gospodarza wersji Linux i wersja gcc ..

ten kod w brzękiem, który należy dodać ścieżkę do 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"))); 

a GetFilePath spróbuje wyszukać pliki z zapytaniem na liście aktualnej ToolChain (plik clang/lib/Driver/ToolChains.cpp). Jeśli nie może znaleźć pliku, zwróci nazwę bez zmian.

Proszę dać mi wersję Ubuntu (uname -a, cat /etc/lsb-release), dokładnie wydanie (numer rewizji svn) z brzękiem i LLVM i gcc -v wyjście

+2

Co ciekawe, implementacja tej funkcji różni się od tej, którą cytowałeś ... Jednak dodanie Paths.push_back ("/ usr/lib"); Paths.push_back ("/ usr/lib/gcc/i486-linux-gnu/4.4/"); załatwił sprawę. Jeśli poprawnie odczytam kod, to mam go tylko w/usr/lib, gdy nie istnieje/usr/lib64. Jednak ten katalog istnieje w moim systemie – Ben04

+0

był bardzo stary cytat. teraz dostaję http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ i mogę sprawdzić kod dla kombinacji clang rev, ubuntu i gcc wersji – osgx

+0

Kod 'GetFilePath()' trys aby otworzyć żądany plik (crt1.o) w każdym katalogu na liście 'getFilePaths()'. Zatrzyma się, jeśli gdzieś znajdzie się plik lub zwróci nazwę pliku bez ścieżki – osgx

1

Ten okropny hack "naprawia" kompilowanie/łączenie z brzękiem 3.0 (r142716) Ubuntu 11.10 (x86)

zawarte w pliku z /usr/include/stdio.h:28:
/usr/include/features.h:323:10 poważny błąd: „bitów/predefs. h nie znaleziono pliku

/usr/bin/ld: nie można znaleźć crt1.o: Nie plik lub katalog
/usr/bin/ld: nie można znaleźć crti.O: Nie ma takiego pliku lub katalogu

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

Ta poprawka nie jest już potrzebna od r143344, r143345, r143346. Problem powinien zostać naprawiony teraz. patrz http://llvm.org/bugs/show_bug.cgi?id=11223 – Peter

0

run:

clang -v 

w moim przykładzie wyjście jest:

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

uruchom następujące jako root używać target stworzyć brakuje katalogu jako link:

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

W najnowszej wersji (3.5) ten problem pojawił się ponownie u każdego, kto tworzy kompilację przy użyciu opcji konfiguracyjnej --with-gcc-toolchain w systemie z zainstalowaną biblioteką pre-gcc 4.7 libstdC++.

Zobaczysz ją w dwóch smakach:

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

... jak również nie jest zamiar znaleźć różne pliki CRT.

W obu przypadkach następuje pozwala obejść ten problem, dopóki nie zostanie ustalone: ​​

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 
Powiązane problemy