RFC: Standardize Clang Resource Directory as /usr/lib/clang/${version}

LLVM Project
1

I would like to propose that we make the default Clang Resource Directory /usr/lib/clang/${version}. The current default is /usr/lib${LLVM_LIBDIR_SUFFIX}/clang/${version}. LLVM_LIBDIR_SUFFIX is mainly used on 64-bit targets, where it is set to 64 to ensure that the libLLVM and libClang libraries get installed into /usr/lib64.

One of the main problems with having the Clang Resource Directory in /usr/lib64 is that the clang driver is unable to find 32-bit run-time libraries which are usually built with LLVM_LIBDIR_SUFFIX=“”, and end up installed to /usr/lib/clang/${version}. When clang is built with LLVM_LIBDIR_SUFFIX=64, it will only look for runtime libraries in /usr/lib64/clang/${version}.

There is also precedent for using /usr/lib for the resource directory. gcc uses /usr/lib/gcc/${triple}/${version} for its own ‘resource directory’

Linux distros like including Debian, Ubuntu, and Gentoo all use the /usr/lib prefix, and Fedora is planning to switch to /usr/lib for the Fedora-39 release.

Having a single standard value will not only fix the multilib issue mentioned above, but it will also simplify the build system and reduce the number of cmake option combinations that we need to support.

Thanks,
Tom

3 Likes
2

Is the proposal is to drop the LLVM_LIBDIR_SUFFIX=64 effect on changing the resource directory to dirname(clang)/../lib64/clang/${version}? I fully support this!

The default is dirname(clang)/../lib/clang/${version}. When clang is at /usr/bin/clang, the resource directory is at /usr/lib/clang/${version}. dirname(clang)/../lib64/clang/${version} is currently used with LLVM_LIBDIR_SUFFIX=64.

Some distributions use this systemd specified file hierarchy: file-hierarchy . It says:

/usr/lib/

Static, private vendor data that is compatible with all architectures (though not necessarily architecture-independent). Note that this includes internal executables or other binaries that are not regularly invoked from a shell. Such binaries may be for any architecture supported by the system. Do not place public libraries in this directory, use $libdir (see below), instead.

/usr/lib/arch-id/

Location for placing dynamic libraries into, also called $libdir. The architecture identifier to use is defined on Multiarch Architecture Specifiers (Tuples) list. Legacy locations of $libdir are /usr/lib/, /usr/lib64/. This directory should not be used for package-specific data, unless this data is architecture-dependent, too. To query $libdir for the primary architecture of the system, invoke: […]

# Debian GNU/Linux
% systemd-path system-library-arch
/usr/lib/x86_64-linux-gnu
% systemd-path system-library-private
/usr/lib

# Arch Linux
% systemd-path system-library-arch
/usr/lib
% systemd-path system-library-private
/usr/lib

The main purpose of the Clang Resource Directory is for builtin-headers (used by all --target=XXX), which satisfy the “Static, private vendor data” criterion. (Some compiler-rt libraries are also there, but they can be considered private as well: they are supposed to be used by Clang Driver, and in the future, lld-link, not by projects specifying -lxxx).

In the long term, I want that LLVM_LIBDIR_SUFFIX as a toggle to be completely removed. I think it is an old-day solution that has a modern idiom replacement.
Although I am not familiar with how distributions install llvm, clang, and other llvm-project subprojects, I believe there is a better way to customize their location.

3

Yes, exactly.