Le 05/03/2020 à 00:03, Lisandro Damián Nicanor Pérez Meyer a écrit : > Hi again. > > On Wed, 4 Mar 2020 at 19:45, Alexis Murzeau <amub...@gmail.com> wrote: >> >> Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit : >>> Hi! >>> >>> El mié., 4 mar. 2020 18:11, Alexis Murzeau <amub...@gmail.com> escribió: >>> >>>> Hi, >>>> >>>> I've a question about whether libclang1-X should depend on >>>> libclang-common-X-dev to always have the clang's builtin headers >>>> available when libclang is installed. >>>> >>> >>> Definitely not. Headers should depend upon the library, not the other way >>> around. >>> >>>> >>> >> >> Why do you think that ? > > Because development files should depend upon the libraries they > provide the headers for, not the other way around. It's the basics of > library packaging.
libclang-common-X-dev contains clang's builtin headers which are not the same as libclang API headers. clang's builtin headers are not the ones providing the API of libclang but compiler builtin functions like _mm_sqrt_ps using clang's specific functions like __builtin_ia32_sqrtps. The package that contains libclang's API headers is libclang-X-dev, not libclang-common-X-dev. So to sum up, clang has: - libclang-X-dev: libclang's API headers containing functions available in libclang to manipulate AST, compile code, ... (for example ASTMutationListener.h, CompilerInstance.h, CXCompilationDatabase.h, ...) - libc++-X-dev: clang's libc++ standard library headers (for example vector, unordered_map, ...) - libc6-dev: GNU C standard library headers (for example stdlib.h, stdio.h, ...) - libclang-common-X-dev: clang's builtin headers (for example, immintrin.h, stddef.h, x86intrin.h, ...) And there is also libllvm API headers: - libllvm-X-dev: llvm's API headers (for example IRReader.h, LinkTimeOptimizer.h, ...) > > [snip] >> If libclang1-X should not depend on libclang-common-X-dev, then users of >> libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile >> code from source should depend themselves on libclang-common-X-dev as it >> is required for them to work correctly. > > And then again, wrong. Making an IDE show the header a compiler is > **NOT** using it's plain **WRONG**. I already expressed that in the > bug upstream and in Qt Creator's bug. Note that I did even stress the > question in upstream's bug just to show that nobody could say > otherwise. Neither Marko nor Thiago denied that. This may be wrong, but having parse errors because of issues like "fatal error: 'stddef.h' file not found" is not better. It makes qtcreator's code model to fail to parse code, which is one of the key feature of an IDE like this. It's better have the IDE use clang's builtin headers than not being able to parse code because of missing builtin headers. > > So if you want a fix make clang understand other compiler's headers, > or provide a better code parser. Currently, whatever if this is right or wrong, the only way to fix "fatal error: 'stddef.h' file not found" when using qtcreator or kdevelop on Debian is to install the appropriate libclang-common-X-dev. The toolchain used to parse the code model for qtcreator and the toolchain used to actually compile the code can be different, but that doesn't matter because clang already provide the appropriate *builtin* headers to make other compilers specific functions also available with clang. For example, gcc provides the non standard function _get_ssp available from immintrin.h [0], clang also does provide it in cetintrin.h builtin header which is included by its own immintrin.h builtin header. MSVC provides _InterlockedCompareExchange_HLEAcquire function (which is specific to MSVC as said in [1]), clang also provides it in the same immintrin.h builtin header (even on linux, these builtin headers are in libclang-common-X-dev package. Or maybe guarded with some #ifdef). So while clang support other compilers specifics, it still needs to have its matching *builtin* headers (which are mostly only intrinsics or platform specific stuff) as builtin headers of each compilers are probably highly specific to the compiler they are made for (which are different from API headers or C and C++ standard library headers). > > Regards, Lisandro. > > [0] https://gcc.gnu.org/onlinedocs/gcc/x86-control-flow-protection-intrinsics.html#x86-control-flow-protection-intrinsics [1] https://docs.microsoft.com/fr-fr/cpp/intrinsics/interlockedcompareexchange-intrinsic-functions?view=vs-2019 -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
signature.asc
Description: OpenPGP digital signature
