Używam clang-3.5
do szczęśliwie zbudować wersje bitcode musl libc i użyć wyniku, aby produkować ładne samodzielne pliki wykonywalne.clang-3.8 i kompilator-rt vs libgcc
Ostatnie próby z clang-3.8
nie były tak szczęśliwe. Wydaje się, że bitcode clang-3.8
generuje używa funkcji zdefiniowanych w
compiler-rt/lib/builtins
Typowymi przykładami funkcji Uważam zanieczyszczających bitcode są mulxc3
, mulsc3
i muldc3
. Mogę to rozwiązać, łącząc się z libgcc
lub nawet z alternatywą dla llvm, gdybym miał jakąkolwiek jasność co to było. Chociaż wolałbym raczej zapobiec temu problemowi w pierwszej kolejności.
Widziałem wzmiankę o flagach takich jak rtlib=compiler-rt
itp., Ale znalazłem cenną małą dokumentację na ten temat.
Oto kilka prostych pytań.
Czy to możliwe, aby zapobiec
clang
z użyciemcompiler-rt/lib/builtins
w emitowanym bitcode? Lub jeśli nieCzy llvm produkuje wersję libgcc, które mogłem użyć. Właściwie mógłbym prawdopodobnie zbudować wersję bitcode, ale to poza tym.
Uwielbiam słuchać wskazówek na ten temat.
Dodane 08.12.2016: Więc będę zilustrować moje problemy z konkretnym workflow że ludzie mogą rozmnażać, jeśli chcą, albo, co bardziej prawdopodobne, po prostu skieruj się, gdzie jestem głupi.
Więc zacznij od sprawdzenia się:
i postępuj zgodnie z instrukcjami zawartymi w README.to kompilacji (tu używam dzyń-3.8 na ubuntu 14.04)
WLLVM_CONFIGURE_ONLY=1 CC=wllvm ./configure --target=LLVM --build=LLVM
make
cd lib
extract-bc -b libc.a
będziesz również potrzebujesz bitu z prostego pliku wykonywalnego. Użyję tutaj nweb.c.
wllvm nweb.c -o nweb
extract-bc nweb
Teraz możemy robić takie rzeczy jak:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
Ten obieg idzie gładko brzękiem-3.5, ale dla brzękiem-3.8 otrzymujemy:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
/tmp/libc-f734a3.o: In function `cpowl':
libc.a.bc:(.text+0xbb9a): undefined reference to `__mulxc3'
/tmp/libc-f734a3.o: In function `cpowf':
libc.a.bc:(.text+0x38f7d): undefined reference to `__mulsc3'
/tmp/libc-f734a3.o: In function `csqrt':
libc.a.bc:(.text+0x78fc3): undefined reference to `__muldc3'
/tmp/libc-f734a3.o: In function `cpow':
libc.a.bc:(.text+0xafafc): undefined reference to `__muldc3'
clang-3.8: error: linker command failed with exit code 1 (use -v to seeinvocation)
Tak jak wskazuje @ Paul Brannan moglibyśmy spróbować
clang -static -nostdlib --rtlib=compiler-rt nweb.bc libc.a.bc crt1.o libc.a -o nweb
Ale to gdzie ja prawdopodobnie głupi, bo otrzymujemy:
clang-3.8: warning: argument unused during compilation: '--rtlib=compiler-rt'
bez względu na to, czy używam go jako flagi łączącej lub kompilującej.
Nie znam odpowiedzi na to pytanie, ale uważam, że ten raport o błędzie jest istotny: https://llvm.org/bugs/show_bug.cgi?id=16404 BTW, łączenie za pomocą --rtlib = compiler-rt rozwiązał moje problemy z łączeniem, szukając __muloti4, podczas gdy linkowanie z libgcc nie działało. –
Dzięki za cynk @ paul-brannan, wygląda "can-o-wormish". Mimo to wydaje mi się, że nie dotykam Midasa. Wezwę obserwację, aby ludzie mogli zduplikować mój problem i zaprowadzili mnie do obiecanej ziemi. –
Dodaję to tutaj, ponieważ chociaż nie odpowiada na moje pytanie, wydaje się również istotne. [Twórz pliki GNU wolne od klangów] (https://blogs.gentoo.org/gsoc2016-native-clang/2016/05/31/build-gnu-free-executables-with-clang/) –