GNOME Bugzilla – Bug 781872
Clang sysdep is broken
Last modified: 2021-05-12 14:35:53 UTC
The clang sysdep is broken. It's installing llvm-devel on Fedora, but it needs to install clang-devel. The right fix is to look for clang-c/Index.h under /usr/include instead of llvm-config in PATH. This is easy to fix. On Ubuntu/Debian, we want it to install one of the libclang-dev packages, but it is currently installing the llvm package. I don't know how to fix this though, because libclang-dev does not install any pkg-config nor anything under PATH. Since I don't know how to fix this, I'll leave it broken. :( I'm not sure about FreeBSD, but I presume it's working properly since Ting-Wei developed this in bug #754041. Note: I'm also renaming this from "clang" to "libclang" for clarity. The only thing that needs it is GNOME Builder.
The following fix has been pushed: d7c30a8 Fix installation of libclang dependency (at least on Fedora)
Created attachment 350609 [details] [review] Fix installation of libclang dependency (at least on Fedora) Also, rename to libclang, since that's what we need. Don't care if it installs the compiler itself or not.
Debian is definitely still broken. We need to invent some way to install libclang-dev.
(In reply to Michael Catanzaro from comment #0) > The clang sysdep is broken. It's installing llvm-devel on Fedora, but it > needs to install clang-devel. The right fix is to look for clang-c/Index.h > under /usr/include instead of llvm-config in PATH. This is easy to fix. The clang sysdep did use clang-c/Index.h when it was added to gnome-sysdeps-3.18.modules. JHBuild had no support for alternative locations of dependencies then, so commit f2275e9 updated it to use llvm-config to keep it working on both Fedora and Debian. It was later changed to use the newly introduced <altdep> tag because I wanted to make modulesets work on FreeBSD, but I didn't remember to change the clang sysdep check back to the more correct header check. > > On Ubuntu/Debian, we want it to install one of the libclang-dev packages, > but it is currently installing the llvm package. I don't know how to fix > this though, because libclang-dev does not install any pkg-config nor > anything under PATH. Since I don't know how to fix this, I'll leave it > broken. :( Debian allows installing multiple versions of clang. libclang-dev is used as a meta-package that pulls in a versioned package, such as libclang-3.8-dev. I think we can use <altdep type="c_include" name="../lib/llvm-4.0/include/clang-c/Index.h"/> <altdep type="c_include" name="../lib/llvm-3.9/include/clang-c/Index.h"/> <altdep type="c_include" name="../lib/llvm-3.8/include/clang-c/Index.h"/> to find and install versioned packages (libclang-4.0-dev, libclang-3.9-dev, libclang-3.8-dev) on Debian. However, we cannot know whether the version installed by 'jhbuild sysdeps --install' is the default version used by Debian. > > I'm not sure about FreeBSD, but I presume it's working properly since > Ting-Wei developed this in bug #754041. FreeBSD also allows installing multiple versions of clang. 'jhbuild sysdeps --install' cannot work on FreeBSD because its package manager cannot search uninstalled packages by file names. Bug #754041 only makes JHBuild be able to find llvm and clang on FreeBSD, so we can use 'jhbuild build' without '--nodeps' or '--skip=llvm --skip=clang'. The c_include paths we need here are: <altdep type="c_include" name="../llvm40/include/clang-c/Index.h"/> <altdep type="c_include" name="../llvm39/include/clang-c/Index.h"/> <altdep type="c_include" name="../llvm38/include/clang-c/Index.h"/> There is no recommended or default libclang version on FreeBSD, and libLLVM* and libclang are put in the same package since version 3.7. FreeBSD users seldom have to manually install llvm* package because llvm40 is pulled in by mesa.
(In reply to Ting-Wei Lan from comment #4) > Debian allows installing multiple versions of clang. libclang-dev is used as > a meta-package that pulls in a versioned package, such as libclang-3.8-dev. > I think we can use > > <altdep type="c_include" name="../lib/llvm-4.0/include/clang-c/Index.h"/> > <altdep type="c_include" name="../lib/llvm-3.9/include/clang-c/Index.h"/> > <altdep type="c_include" name="../lib/llvm-3.8/include/clang-c/Index.h"/> > > to find and install versioned packages (libclang-4.0-dev, libclang-3.9-dev, > libclang-3.8-dev) on Debian. However, we cannot know whether the version > installed by 'jhbuild sysdeps --install' is the default version used by > Debian. JHBuild will always pick the first package to be printed by apt-file, so I think it will always pick the one with the biggest version number. That's not likely to be Debian or Ubuntu's default version of clang, but I don't think that matters very much. What I'm not sure about is if that relative path is going to work. I don't think so. I think JHBuild will literally search apt-file for "../lib/llvm-4.0/include/clang-c/Index.h" and the search will fail because no package contains any results including "../lib". This is a limitation of the apt backend. (Note: I have not tested this just now, but I think that's how it works, from past experience.) Ideally, we would remove the apt backend in favor of the PackageKit backend, but my understanding is the PackageKit backend has problems on Debian and Ubuntu. (I haven't tested that either, but the apt backend has to exist for a reason.)
Right, I don't think Debian/Ubuntu's PackageKit supports searching for filenames: https://bazaar.launchpad.net/~ubuntu-desktop/yelp/ubuntu/view/head:/debian/patches/07_disable_package_search.patch I think that often the default clang on Debian or Ubuntu would be the one with the highest version number (I think that's true for Ubuntu and Debian stretch right now but not Debian unstable).
I think we need to bite the bullet and add a way to install packages that provide arbitrary files. This would be useful in a variety of other situations where we are not currently able to install sysdeps automatically.
See https://gitlab.gnome.org/GNOME/jhbuild/-/issues/85