[OpenMP] Linking uses a `libomptarget` with very narrow version tag

[KaruroChori]

Compiling some demo code with

clang++ main.cpp -fopenmp -g -fopenmp-targets=amd64-linux-unknown

and checking the linked libraries results in these two entries related to OpenMP:

• libomp.so
• libomptarget.so.21.0git

The second is using a specific version tag which is quite bad for portability. Is there any good reason why?
The version tested is pretty much the latest commit.

[llvmbot]

@llvm/issue-subscribers-openmp

Author: None (KaruroChori)

Compiling some [demo code](https://godbolt.org/z/5oqE4Es6q) with ```bash clang++ main.cpp -fopenmp -g -fopenmp-targets=amd64-linux-unknown ``` and checking the linked libraries results in these two entries related to OpenMP: - `libomp.so` - `libomptarget.so.21.0git`

The second is using a specific version tag which is quite bad for portability. Is there any good reason why?
The version tested is pretty much the latest commit.

[jhuber6]

So, this is mostly because libomptarget is an LLVM library and libomp is not. The former gets the version appended automatically. However, we have constant issues with people picking up incorrect versions of libomptarget for all intents and purposes, we consider these libraries to be tied to the compiler and they're not really backward compatible (like LLVM). There have been recent discussions about making this even more obvious, like trying to run with an old library emitting some warnings or something.

[KaruroChori]

So, best strategy is just to statically link that one for distribution?
It would be very strange to make assumptions on which compiler version if any is installed on the user's side.

[jhuber6]

Shared libraries give you reference counting, which is important for libraries like this which seek to manage hardware resources like threads and GPU devices. Otherwise, if someone creates a shared library with OpenMP and links it in, you'll have multiple versions of libomptarget running at the same thing, both thinking they have exclusive access to the GPU.

[KaruroChori]

If that is the case, would it not break down regardless when trying to package an application as a flatpack for example?
Or just running it in a docker container?
Or what if I have multiple versions of llvm installed on my system, and different applications using different versions of libomptarget?

[jhuber6]

If that is the case, would it not break down regardless when trying to package an application as a flatpack for example? Or just running it in a docker container? Or what if I have multiple versions of llvm installed on my system, and different applications using different versions of libomptarget?

That would be up to whatever ld.so picks up first, mostly controlled by -rpath. It's one of the common failure modes, someone picks up an old libomptarget from their system when they wanted the new one.

[KaruroChori]

Ok, so the problem is not having libomptarget.so.21.0 and libomptarget.so.20.0 on the same system, or possibly many more copies considering flatpaks.
As long as an application and everything linked in its tree is using just one of them we are fine.
The issue is when they get mixed. And you were suggesting that statically linking it is a very bad idea because this would be like linking two or more copies with split states. Basically same "bad scenario" as for glibc.

This sadly leaves the issue of distribution unresolved.
Assuming user's will have clang-21 on their systems, or whichever version is used for the release build, is just not feasible.
And as far as I know there is no distribution of libomptarget as a standalone library which could be simply required as a dependency.

Is there anything specific which prevents some degree of forwards and backwards binary compatibility?
Or at the very least its distribution as a standalone library in distros?

[jhuber6]

Compatibility is somewhat due to LLVM, but mostly because no one ever defined a decent API and forced it to be backward compatible.