After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 781872 - Clang sysdep is broken
Clang sysdep is broken
Status: RESOLVED OBSOLETE
Product: jhbuild
Classification: Infrastructure
Component: module sets
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Jhbuild maintainers
Jhbuild QA
Depends on:
Blocks:
 
 
Reported: 2017-04-28 00:29 UTC by Michael Catanzaro
Modified: 2021-05-12 14:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix installation of libclang dependency (at least on Fedora) (4.00 KB, patch)
2017-04-28 00:59 UTC, Michael Catanzaro
committed Details | Review

Description Michael Catanzaro 2017-04-28 00:29:59 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.
Comment 1 Michael Catanzaro 2017-04-28 00:59:32 UTC
The following fix has been pushed:
d7c30a8 Fix installation of libclang dependency (at least on Fedora)
Comment 2 Michael Catanzaro 2017-04-28 00:59:36 UTC
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.
Comment 3 Michael Catanzaro 2017-04-28 03:40:00 UTC
Debian is definitely still broken. We need to invent some way to install libclang-dev.
Comment 4 Ting-Wei Lan 2017-04-28 16:30:33 UTC
(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.
Comment 5 Michael Catanzaro 2017-04-28 18:40:13 UTC
(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.)
Comment 6 Jeremy Bicha 2017-04-28 18:52:22 UTC
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).
Comment 7 Michael Catanzaro 2017-05-02 15:16:05 UTC
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.
Comment 8 André Klapper 2021-05-12 14:35:53 UTC
See https://gitlab.gnome.org/GNOME/jhbuild/-/issues/85