Padrão incorreto inclui diretórios para clang cross-compile?

1

Minha máquina de compilação é xenial x86_64. Eu sou cross-compiling para arm-linux-gnueabihf. Eu instalei o g ++ - arm-linux-gnueabihf.

Ao criar com clang++ --target=arm-linux-gnueabihf , recebo o erro " /usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0/../../../../include/c++/5.4.0/string:38:10: fatal error: 'bits/c++config.h' file not found ". Mas por que está lendo /usr/include/c++/5/string ?

Usando o comando sugerido em "Dump include paths from g ++" , verifico os caminhos de inclusão para arm-linux-gnueabihf-g++ :

$ /usr/bin/arm-linux-gnueabihf-g++ -E -x c++ - -v < /dev/null
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-linux-gnueabihf-g++
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 
COLLECT_GCC_OPTIONS='-E' '-v' '-shared-libgcc' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
 /usr/lib/gcc-cross/arm-linux-gnueabihf/5/cc1plus -E -quiet -v -imultiarch arm-linux-gnueabihf -D_GNU_SOURCE - -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -fstack-protector-strong -Wformat -Wformat-security
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory "/usr/include/arm-linux-gnueabihf"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/include/c++/5
 /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/include/c++/5/arm-linux-gnueabihf
 /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/include/c++/5/backward
 /usr/lib/gcc-cross/arm-linux-gnueabihf/5/include
 /usr/lib/gcc-cross/arm-linux-gnueabihf/5/include-fixed
 /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/include
 /usr/include
End of search list.

Depois, verifico os caminhos de inclusão para clang++-3.8 --target=arm-linux-gnueabihf :

$ /usr/bin/clang++-3.8 --target=arm-linux-gnueabihf -E -x c++ - -v < /dev/nullclang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: arm--linux-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0
Found candidate GCC installation: /usr/lib/gcc-cross/arm-linux-gnueabihf/5.4.0
Selected GCC installation: /usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0
Candidate multilib: .;@m32
Selected multilib: .;@m32
 "/usr/lib/llvm-3.8/bin/clang" -cc1 -triple armv6kz--linux-gnueabihf -E -disable-free -disable-llvm-verifier -main-file-name - -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu arm1176jzf-s -target-feature +strict-align -target-abi aapcs-linux -mfloat-abi hard -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0 -internal-isystem /usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0/../../../../include/c++/5.4.0 -internal-isystem /usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0/../../../../include/arm-linux-gnueabihf/c++/5.4.0 -internal-isystem /usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0/../../../../include/arm--linux-gnueabihf/c++/5.4.0 -internal-isystem /usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0/../../../../include/c++/5.4.0/backward -internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/leo/ws/odroid_ws -ferror-limit 19 -fmessage-length 157 -fallow-half-arguments-and-returns -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o - -x c++ -
clang -cc1 version 3.8.0 based upon LLVM 3.8.0 default target x86_64-pc-linux-gnu
ignoring nonexistent directory "/usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0/../../../../include/arm-linux-gnueabihf/c++/5.4.0"
ignoring nonexistent directory "/usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0/../../../../include/arm--linux-gnueabihf/c++/5.4.0"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0/../../../../include/c++/5.4.0
 /usr/bin/../lib/gcc-cross/arm-linux-gnueabihf/5.4.0/../../../../include/c++/5.4.0/backward
 /usr/local/include
 /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include
 /usr/include
End of search list.

Eu noto (depois de usar o readlink para remover a bagunça ../ .. dos caminhos):

arm-linux-gnueabihf-g++ usa / usr / arm-linux-gnueabihf / include / c ++ / 5 e não usa / usr / include / c ++ / 5.

clang++ --target=arm-linux-gnueabihf usa / usr / include / c ++ / 5 e não usa / usr / arm-linux-gnueabihf / include / c ++ / 5.

O clang está errado? O que posso fazer para corrigir isso?

    
por Lack 20.08.2017 / 06:04

2 respostas

0

Ainda não sei o que está errado com o clang e / ou com a configuração do meu sistema, mas usei esses sinalizadores como uma solução alternativa:

-nostdinc++ -cxx-isystem /usr/arm-linux-gnueabihf/include/c++/5 -cxx-isystem /usr/arm-linux-gnueabihf/include/c++/5/arm-linux-gnueabihf

    
por Lack 30.08.2017 / 23:14
0

Você pode usar --sysroot=/usr/arm-linux-gnueabihf/sys-root neste caso. O Clang, a partir do 6.0 (ATM não-liberado), parece contornar as inúmeras maneiras pelas quais as bibliotecas e ferramentas GNU (gcc, glibc e libstdc ++ em particular) são dispostas nas distribuições Linux. Você ainda pode ter alguns problemas, que é onde usar

clang -v ...

bem como

strace -e 'trace=!write' clang ...

para ver os diretórios que o Clang está procurando ajudará. Eu encontrei uma solução hacky no Fedora. Eu estou fazendo atualmente:

(Estou usando o gcc 7 e clang aqui, e <sysroot>=/usr/arm-linux-gnueabihf/sys-root )

  1. Instale os pré-requisitos de compilação cruzada (varia de acordo com a distribuição, mas o Fedora tem um pacote de sistema de arquivos que cria a pasta <sysroot> ). Isso também inclui todos os binários e cabeçalhos de desenvolvimento para sua plataforma de destino. Infelizmente, não há ótimas soluções prontas para isso em muitas plataformas. Por exemplo, o Fedora não possui libstdc++ para o aarch64, mas o IIRC Debian e o Ubuntu têm isso.

  2. Crie um sysroot para a plataforma

    mkdir -p <sysroot>/lib/gcc
    ln -s <sysroot>/include <sysroot>/usr/include # Another Clang quirk, it seems
    
  3. Copie os binários do GCC e os cabeçalhos do libstdc ++. Isso é um pouco frustrante, pois a forma como a Clang procura as instalações do GCC é pesquisando caminhos comuns ( por exemplo, , /usr/lib/gcc/x86_64-linux-gnu ) e indo até um número X de diretórios para encontrar cabeçalhos associados. Isso significa que, a menos que você possa criar hard links de seus binários gcc para sua nova raiz de sistema, você precisará copiar os binários e (alguns) cabeçalhos. Isso é o que eu tive que fazer para que isso funcionasse (pode ser diferente para você):

    cp -r /usr/lib/gcc/arm-linux-gnueabihf/ <sysroot>/lib/gcc
    # Fedora installs C++ headers here, but we will copy them into sys-root
    # Copy all of your other headers in the same manner
    cp -r /usr/arm-linux-gnueabihf/include/c++ <sysroot>/include
    
  4. Adicione o sinalizador --sysroot= para clangar

    clang --target=arm-linux-gnueabihf --sysroot=<sysroot> ...
    

A maior parte da lógica do Clang que lida com a busca por esses diretórios parece estar dentro desses arquivos (eles podem não existir em versões mais antigas do Clang):

lib / Driver / Tags de ferramentas / Gnu.cpp

lib / Driver / Chaves de ferramentas / Linux.cpp

    
por Daniel Wright 26.01.2018 / 05:30