Libclangbasic.a Not Found
Adah Orhenkowski
I need to install the clang suite of compilers and the apt command is giving me errors. I've searched many possible solutions but so far none of the recommendations I have found to solve similar problems have helped. Here is what I get when I try apt install clang :
When I did sudo aptitude install clang, I got the same message as shown, but then typed 'n'. Aptitude then offers another solution, which is to offer to 'downgrade' to gcc 9. Allow it to do that, and let it return to the command prompt. Then then do sudo apt install clang and you'll get clang-10.
Sounds like you are running into conflicts for some reason. The root cause might be that you enabled non-Ubuntu package repositories after upgrading that aren't 100% compatible with Ubuntu 20.04? If so consider removing them from /etc/apt/sources.list.d/ and run apt update.
If that doesn't help, I would recommend running aptitude interactively. It proposes solutions and allows you to resolve them in a semi-automatic way. You might also want to keep an eye on "held" packages. It often helps to upgrade them. To do so start aptitude in interactive mode and press Shift+U, then G twice.
After Meeting C++ 2016 I decided to port the codegen tool to C++ writingmy own libclang C++ wrapper, but ultimately@foonathan won the race with what has becomecppast. So there I was, with almosttwo years of work going nowhere for different reasons. It was time to goback to the start and analyzing my requirements from scratch.
So as of September 2017 I started playing with a new concept: Staticreflection with an API as simple as possible, customizable metadataindependent from the reflection API, cross compilation support since day1, and a codegen tool written with C++ and cppast:tinyrefl
In addition conan has a lot of customization features for your recipes,like package options, header only lib mode, overriding settings dependingon the target toolchain, etc. See the conandocs for details.
LLVM and its components (LLVM, Clang, compiler-rt, libc++, etc) use a lotof common CMake scripts contained in the LLVM repo. Forget about writingisolated libraries depending on each other. If you want to build LLVM fromsources you have to build all of it, and if you want to build Clangyou have to build it as part of LLVM or build it out of LLVMsourcetree somehow.
After almost a year and a half of trial and error, inheriting from someearlyattempts,I found a way to build each component separately in its own package:Patch the main CMakeLists.txt file of the component to import the CMakescripts from LLVM:
The most important line is list(APPEND CMAKE_PROGRAM_PATH$CONAN_BIN_DIRS) which adds the bin/ directories of the conandependencies to the set of paths that CMake uses to search programsthroughfind_program()calls. This allows components such as Clang or libc++ to findllvm-config utility from LLVM, which is compiled and packaged by theLLVM build. LLVM components use llvm-config to figure out where LLVM wasinstalled (The LLVM conan package directory in this case) and get thecommon CMake scripts from there.
The cool thing about this approach is that I not only inject the path tollvm-config but also the full conan deps configuration, which meansI have full control of the component dependencies. I can point anyexternal dependency to a conan package, making the build system dependencyfree.
Having one huge package forLLVMand another huge package forClangis a big leap forward compared to having nothing in conan, but it comeswith some caveats. In order to use those packages you either have to usethe official LLVM cmake scripts (Which are ratherobfuscatedand lack dependency resolution), or do it the conan way, requesting thecomponent as a dependency and linking it in your project:
However this last snippets may not be a solution to the problem, sincewhat that cmake script is doing is to link mycppparser against everyLLVM, compiler-rt, and Clang library. Remember that collect_libs()call in package_info()?
Write a conan recipe for each module to package the corresponinglibrary file. Libraries are copied from their parent componentpackage, no individual compilation of each lib is done.
Points 1. and 3. are the usual monkey manual work that requires patienceand tens of liters of coffee. I managed to get the work done in one of mystraight-12-hours-not-moving-my-ass-from-the-computer weekendprogramming sessions by a combination of manually inspecting each libraryCMakeLists.txt file andlddtree.For reference, this is the dependency tree of libclang 6.0.1:
Points 2, and 4. are solved through one of the latest conan features,python_requires() which allows packaging python modules and conanrecipes (base recipes, think of them as recipe templates) and reuse themto write another recipes.
Well, I would say the first next step is to add windows workers to the CIpipeline. I already did some early tests of this recipes on windows andit seems to work ok, so I will push the work once I begin working on MSVCsupport for tinyrefl (See tinyrefl roadmaphere).
Oh, also packaging libtinfo with conan to get rid of that systemdependency. Any volunteer? Please?