c++ - tutorial - visual studio installer

¿Cómo forzar el clang para usar alguna biblioteca por defecto?

Question

Construyo clang por clang contra libc ++ , libc ++ abi , compiler-rt en los siguientes pasos:

• Para descargar (y actualizar) llvm y los subproyectos, uso el siguiente script:

  svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
  cd llvm/tools
  svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
  svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk clang/tools/extra
  svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb
  svn co http://llvm.org/svn/llvm-project/lld/trunk lld
  svn co http://llvm.org/svn/llvm-project/polly/trunk polly
  cd ../projects/
  svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
  svn co http://llvm.org/svn/llvm-project/libunwind/trunk libunwind
  svn co http://llvm.org/svn/llvm-project/openmp/trunk openmp
  svn co http://llvm.org/svn/llvm-project/libcxxabi/trunk libcxxabi
  svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx

• Primero que todo, compilo llvm , clang , libunwind contra libgcc y libstdc ++ usando gcc e instalo en /usr/local . En todos los pasos siguientes, excepto el último, uso este nuevo clang / clang++ .

• Luego construyo por separado libunwind , tanto las versiones de 32 bits como las de 64 bits (son esenciales, como lo será más adelante, porque asan necesita las versiones de 32 bits de algunas bibliotecas durante la compilación final de todo el árbol del proyecto) e instalo en /usr/local/lib y /usr/local/lib32 correspondiente (también actualizo LD_LIBRARY_PATH respectivamente).
• Cree bibliotecas ABC de libcxxrt en versiones de 32 y 64 bits e instálelas correctamente.
• Genere libcxx contra libcxxrt en versiones de 32 y 64 bits e instálelas correctamente.
• Luego compile libc ++ abi contra libc ++ en versiones de 32 y 64 bits e instálelos correctamente.
• Luego compile libc ++ contra libc ++ abi en versiones de 32 y 64 bits e instálelos correctamente sobre la versión anterior vinculada a libcxxrt .
• Después de todo, construyo todo el árbol del proyecto contra libc ++ , libc ++ abi , libunwind , compiler-rt y lo instalo sobre el antiguo clang en /usr/local .

(Estoy casi seguro de que ningún paso es redundante aquí).

En el último paso tengo un problema: tengo que agregar parámetros adicionales al vinculador (los agrego a CMAKE_EXE_LINKER_FLAGS y CMAKE_SHARED_LINKER_FLAGS ) -lunwind y -lc++abi . Además, cada vez que uso el clang++ resultante con -stdlib=libc++ y compiler-rt (o, igualmente, CLANG_DEFAULT_CXX_STDLIB=libc++ y CLANG_DEFAULT_RTLIB=compiler-rt ) en mis proyectos tengo que hacerlo una y otra vez. Es molesto. El proyecto CMakeLists.txt Qt Creator debe corregirse a mano o por cmake-gui .

¿Cómo hacer que clang driver especifique automáticamente estas opciones para ld en tiempo de ejecución? ¿Hay algo similar al mecanismo RPATH ? ¿O hay alguna variable específica de CMake (especificada antes del proceso de construcción llvm ) para lograr el comportamiento deseado?

¿Puedo usar RPATH para mis propósitos?

Seguramente no quiero hacer algunos bash -script como wrappers (similar a clang++-libc++ ) para especificar parámetros adicionales. Quiero que las bibliotecas estén codificadas en algún lugar del propio binario de clang .

Answer 1

Hay un par de soluciones han sido sugeridas. Terminé con la siguiente solución:

mkdir build
cd build
# backup:
cp -vaf /usr/local/lib/libc++.{a,so.1.0} /usr/local/lib/libc++abi.{a,so.1.0} /usr/local/lib/libunwind.{a,so.1.0} .
clang -shared -fPIC -pthread -o fuse.so -Wl,--whole-archive libc++.a libc++abi.a libunwind.a -Wl,--no-whole-archive -ldl -lm
ar x libc++.a
ar x libc++abi.a
ar x libunwind.a
ar rc fuse.a *.o
sudo chown root:root fuse.*
sudo cp -vaf fuse.so /usr/local/lib/
sudo ln -svf /usr/local/lib/libc++.so.1 /usr/local/lib/fuse.so
sudo cp -vaf fuse.a /usr/local/lib/
sudo mv -vf /usr/local/lib/libc++.a /usr/local/lib/libc++.a.bak
sudo ln -svf /usr/local/lib/libc++.a /usr/local/lib/fuse.a

Fusiona todas las bibliotecas usadas ( libc++ , libc++abi y libunwind ) en el único archivo *.a o *.so . Luego, libc++.a y libc++.so Se reemplazan con (enlaces a) los archivos ensamblados resultantes, guardando las versiones anteriores para una posible copia de seguridad.

Funciona perfectamente para mí.

Pero esta no es la respuesta. Tal vez algún día el clang no tenga ese problema directamente desde la caja.