Should we continue embed the full llvm version in lib/clang/#.#.#/?

Currently compiler provided versions of headers and sanitizer libraries are installed in PREFIX/lib/clang/#.#.#/{include,lib}. This leads to a lot of churn in the set of installed files over the course of the release (exacerbated by the recent move to doing multiple point releases). It’s not clear to me that this adds value. There might be an argument for the dynamic sanitizer libraries, but for headers and static libraries it sees like it would make more sense to move to lib/clang/MAJOR/{include,lib} since there is no support for multiple compilers with the same prefix.

If we’re worried about permitting ABI breaks in release branches then perhaps we could use MAJOR.MINOR since we’re not supposed to be breaking ABI on patch releases, but I’d like to get away from MAJOR.MINOR.PATCH as it causes a fair bit for churn for no value I can see.

If there is a reason for the current setup I’d like to understand it better.

[This has come up a few times over on in the Release Testers area. I most recently raised the issue here LLVM 14.0.2 Release - #2 by brooks and @tstellar said the current situation is an issue for Fedora]

1 Like

I’m supportive of either MAJOR or MAJOR.MINOR; I have a weak preference for just MAJOR, but we had an ABI breaking minor release not super long ago (LLVM 11), so maybe keeping the extra flexibility is worthwhile. Internally we’ve just moved over to using a wildcard wherever we had to refer to that directory name, since otherwise we’d keep getting spurious breakages on patch releases.

I support MAJOR.MINOR. I think we don’t want to end up in a situation where the only option is to up the major version.

2 Likes

Using MAJOR has the issue that it will disallow multiple versions if a distribution chooses to not use PREFIX in lib/clang/#.#/{include,lib}.

Clang built-in headers, sanitizer runtime libraries, libclang_rt.builtins, etc may all get bug fixes across minor versions. I know that Clang built-in headers may be quite stable.

I’m failing to understand what you’re arguing for.

I don’t think the version number in the path is affected at all by ABI breaking changes to libLLVM.so, so just Major should be safe. I also prefer just having MAJOR in the path.

I think the assumption here is that we don’t want to support installing Clang 12.1.0 and Clang 12.2.0 at the same time in the same libdir prefix. However, we do want to allow installing Clang 11.0.0 and Clang 12.2.0 at the same time. Therefore, we need to keep MAJOR in the pathname, but not any other components.

But: is that actually true? Will we never release a libclang ABI bump within a major LLVM release? Or, if we do so, will we not allow both to co-exist on one system?

Is it even possible to install e.g clang 12.1.0 and clang 12.2.0 to the same prefix currently? I thought all the unversioned file names (e.g. the include/clang, included/clang-c header files) would conflict if you tried this.

I’m not sure whether any distro actually has clang packaged in such a way as to allow this, but…

I’d generally expect include/clang and include/clang-c headers to be in a “devel” package which cannot be parallel installed, while libclang.so.NN along with its corresponding builtin headers and runtime libraries are packaged in such a way that if there are multiple soversions, they CAN be installed in parallel.

Right now there are some dynamic sanitizer libraries installed in the clang lib directory. IMO as long as their ABI is stable I don’t see a lot of value in having one per clang release. FreeBSD doesn’t currently support sanitized code linked dynamically across compiler revisions without a recompile.