Mam wirtualny system Debian, którego używam do tworzenia.

Dzisiaj chciałem spróbować llvm / clang.

Po zainstalowaniu clang nie mogę skompilować moich starych projektów c (z gcc). To jest błąd:

...
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
collect2: ld returned 1 exit status
...

Odinstalowałem clang i nadal nie działało.

Czy ktoś ma pomysł, jak mogę to naprawić?

Debian / Ubuntu

Problem polega na tym, że prawdopodobnie masz tylko gcc dla swojej obecnej architektury i jest to 64-bitowe. Potrzebujesz 32-bitowych plików pomocniczych. W tym celu musisz je zainstalować

sudo apt install gcc-multilib

Pomogło mi utworzenie dowiązania symbolicznego:

sudo ln -s /usr/lib/x86_64-linux-gnu /usr/lib64

Wygląda na to, że podczas gry z llvm / clang (lub menedżer pakietów) usunąłeś wcześniej istniejący standardowy pakiet deweloperski biblioteki C ( eglibc na Debianie) lub może nie miałeś go zainstalowanego w pierwszej kolejności, więc musisz przeinstalować it, teraz, gdy wróciłeś do gcc.

Możesz to zrobić w ten sposób na Debianie:

aptitude show libc-dev

Ubuntu:

apt-get install libc-dev

W systemie Ubuntu, jeśli nie masz libc-dev, ponieważ nie mogę go znaleźć na packages.ubuntu.com, możesz spróbować bezpośrednio zainstalować libc6-dev.

Lub w systemach typu Redhat:

yum install glibc-devel

NB: Chociaż w komentarzach udzielono Ci krótkiej odpowiedzi, oto odpowiedź, więc jest jedna zapisana na wypadek, gdyby ktoś ją spotkał i mógł szukać odpowiedzi, ale nie w komentarzach lub komentarz nie jest dla niego wystarczająco wyraźny .

To jest BŁĄD zgłoszony w starterze, ale istnieje obejście:

Uruchom to, aby zobaczyć, gdzie znajdują się te pliki

$ find /usr/ -name crti*
/usr/lib/x86_64-linux-gnu/crti.o

następnie dodaj tę ścieżkę do zmiennej LIBRARY_PATH

$ export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LIBRARY_PATH

Jeśli używasz wersji testowej Debiana, zwanej „wheezy”, być może ugryzło Cię przejście na multiarchę. Więcej na temat multiarch Debiana tutaj: http://wiki.debian.org/Multiarch

Zasadniczo dzieje się tak, że różne biblioteki specyficzne dla architektury są przenoszone z tradycyjnych miejsc w systemie plików do miejsc specyficznych dla nowej architektury. Dlatego /usr/bin/ldjest zdezorientowany.

Znajdziesz crt1.o w obu /usr/lib64/i /usr/lib/i386-linux-gnu/teraz i będziesz musiał powiedzieć o tym swojemu toolchainowi. Oto dokumentacja, jak to zrobić; http://wiki.debian.org/Multiarch/LibraryPathOverview

Zauważ, że samo utworzenie dowiązania symbolicznego da ci tylko jedną architekturę i zasadniczo wyłączysz multiarchę. Chociaż może to być to, czego chcesz, może to nie być optymalne rozwiązanie.

Po przeczytaniu http://wiki.debian.org/Multiarch/LibraryPathOverview opublikowanego przez jeremiaha znalazłem flagę gcc, która działa bez linku symbolicznego:

gcc -B/usr/lib/x86_64-linux-gnu hello.c

Więc możesz po prostu dodać -B/usr/lib/x86_64-linux-gnudo zmiennej CFLAGS w swoim Makefile.

Aby uzyskać 64-bitową wersję RHEL 7 do kompilacji 32-bitowych programów gcc 4.8, musisz zrobić dwie rzeczy.

1. Upewnij się, że wszystkie 32-bitowe narzędzia programistyczne gcc 4.8 są całkowicie zainstalowane:

   sudo yum install glibc-devel.i686 libgcc.i686 libstdc++-devel.i686 ncurses-devel.i686

2. Kompiluj programy przy użyciu opcji -m32

   gcc pgm.c -m32 -o pgm

skradzione stąd: Jak skompilować 32-bitowe aplikacje na 64-bitowym RHEL? - Musiałem zrobić tylko krok 1.

Jak wyjaśniono w brakującym pliku crti.o , lepiej jest użyć polecenia „gcc -print-search-dirs”, aby znaleźć całą ścieżkę wyszukiwania. Następnie utwórz łącze, jak wyjaśniono powyżej "sudo ln -s", aby wskazać lokalizację crt1.o

To działało dla mnie z Ubuntu 16.04

$ LIBRARY_PATH=/usr/lib/x86_64-linux-gnu
$ export LIBRARY_PATH

./configure --disable-multilib

działa na to

Wpadłem na to w CentOs 5.4. Zauważyłem, że lib64 zawierało pliki crt * .o, ale lib nie zawierało. Zainstalowałem glibc-devel przez yum, który zainstalował bity i386 i to rozwiązało mój problem.

Nawet dostałem ten sam błąd kompilacji, kiedy kompilowałem krzyżowo i686-cm-linux-gcc.

Poniższa opcja kompilacji rozwiązała mój problem

$ i686-cm-linux-gcc a.c --sysroot=/opt/toolchain/i686-cm-linux-gcc

Uwaga: sysroot powinien wskazywać katalog kompilatora, w którym dostępne są usr / include

W moim przypadku toolchain jest zainstalowany w katalogu / opt / toolchain / i686-cm-linux-gcc, a usr / include jest również dostępny w tym samym katalogu

Rozwiązałem to w następujący sposób:

1) spróbuj zlokalizować pliki ctr1.o i ctri.o przy użyciu find -name ctr1.o

W moim komputerze mam następujące informacje: $/usr/lib/i386-linux/gnu

2) Dodaj tę ścieżkę do PATH(również LIBRARY_PATH) zmiennej środowiskowej (aby zobaczyć, jaka jest nazwa: wpisz envpolecenie w terminalu):

$PATH=/usr/lib/i386-linux/gnu:$PATH
$export PATH

Miałem dzisiaj ten sam problem, rozwiązałem go instalując zalecane pakiety: libc6-dev-mipsel-cross libc6-dev-mipsel-cross, libc-dev-mipsel-cross

To zadziałało:

sudo apt-get install libc6-dev-mipsel-cross

W moim przypadku błąd crti.o był spowodowany konfiguracją ścieżki wykonania z Matlaba. Na przykład nie można wykonać pliku, jeśli wcześniej nie ustawiono ścieżki katalogu wykonywania. Aby to zrobić: Plik> setPath, dodaj swój katalog i zapisz.

posługiwać się gcc -B lib_path_containing_crt?.o

W moim przypadku w ogóle Ubuntu 16.04nie mam crti.o:

$ find /usr/ -name crti*

Więc instaluję pakiet deweloperski libc 6 -dev:

sudo apt-get install libc6-dev