libclang produced by 14.0.0.rc1 has wrong so-number

[h-vetinari]

Seen in conda-forge/clangdev-feedstock#165, where we explicitly test for presence of libclang.so.<major_ver> in the installed environment. Turns out, that libclang.so.14.0.0 is created, but not the symlink to libclang.so.14:

-- Installing: /home/conda/feedstock_root/build_artifacts/[...]/lib/libclang.so.14.0.0
-- Installing: /home/conda/feedstock_root/build_artifacts/[...]/lib/libclang.so.13
-- Installing: /home/conda/feedstock_root/build_artifacts/[...]/lib/libclang.so

I searched for other issues, maybe #53932 is related.

[tstellar]

@h-vetinari This is expected. libclang.so ABI usually stays stable across major releases, so we've frozen the soname at libclang.so.13. The plan is to keep it with this name unless the ABI changes.

[h-vetinari]

Well, different people can have different expectations. 😅

From LLVM 8 (at least, didn't check back further) to LLVM 13, the version of libclang.so matched the LLVM major version, so it's perhaps understandable how one might arrive at the expectation that this pattern would continue.

But OK, if this is intentional, then I'll reflect this in our build.

[tstellar]

@h-vetinari There is a libclang.so.14.0.0 symlink you can link against if you need a versioned so name.

[tstellar]

@h-vetinari There is a libclang.so.14.0.0 symlink you can link against if you need a versioned so name.

Ah, I guess you already saw that in the first comment.

[h-vetinari]

@h-vetinari There is a libclang.so.14.0.0 symlink you can link against if you need a versioned so name.

Thanks; I can easily live with an ABI version that's different from LLVM-major. Just wanted to verify that that's intentional.

[h-vetinari]

@tstellar
Another question - sorry if those are basic, but just wanting to check. Is it intentional that currently libclang-cpp.so.14 does bump to 14, whereas libclang.so.13 does not?

I've found set(CLANG_SONAME 13), which is clear enough, but I couldn't figure out where libclang-cpp is created, nor whether it intentionally gets a version or not. The search finds it only twice (and not much different for clang-cpp)

[h-vetinari]

@EugeneZelenko
Could you reopen this please until it's clear whether libclang-cpp should match CLANG_SONAME or not? I'm not in a rush, but I'd like to avoid that it falls through the cracks.

[EugeneZelenko]

Sorry, if I was too fast.

[h-vetinari]

Gentle ping @tstellar (regarding CLANG_SONAME vs. libclang-cpp; libclang is clear already).

[tstellar]

@h-vetinari Changing the soname of libclang-cpp.so is intentional, because the ABI/API is changes with each major version.

[h-vetinari]

Thank you very much for clarifying that. Closing.

[h-vetinari]

Unfortunately, one more question popped up still: the OSX dylib for libclang still gets produced as libclang.14.dylib, even though CLANG_SONAME is set to 13 unconditionally.

Or am I overlooking something again? Can the ABI version be platform-dependent (and if so, is that really desirable...)?

[h-vetinari]

PS. I tried looking for documentation on this, but couldn't find any on it. Indeed, out of all files in the clang/* folder, CLANG_SONAME only appears in clang/tools/libclang/CMakeLists.txt.

[h-vetinari]

Apologies for one last ping @tstellar - CLANG_SONAME doesn't appear to take effect on OSX.

[tstellar]

@h-vetinari This wasn't implemented for OSX, because it didn't already use a linker script.

[h-vetinari]

Thank you very much. What do you think of the following suggestions (not sure if they merit a separate issue)?

1. Make the behaviour of CLANG_SONAME uniform across platforms - I can see no downside to reflect the ABI version across platforms, even if OSX doesn't strictly need it(?). Certainly, it would be one less behavioural difference to keep in mind.
2. Document the behaviour of CLANG_SONAME (independently of the outcome of 1.).

[dileks]

You should simply use something else to make clear ABI = 13 and not use the CLANG_SONAME.

As a workaround:
I symlinked all libclang.so libclang.so.13 libclang.so.14 to libclang.so.14.0.1

Link: https://discourse.llvm.org/t/llvm-14-0-1-schedule-and-release-updates/61227/15

[h-vetinari]

You should simply use something else to make clear ABI = 13 and not use the CLANG_SONAME.

I think using the SONAME to indicate the ABI is quite a traditional approach. Personally I find it trickier that it's not consistent across platforms.

[markmi]

On FreeBSD with ports devel/llvm12 devel/llvm13 and devel/llvm14 installed over time
I ended up with:

# ldconfig -r | grep 'lclang\.'
        554:-lclang.12 => /usr/local/llvm12/lib/libclang.so.12
        559:-lclang.13 => /usr/local/llvm13/lib/libclang.so.13
        569:-lclang.13 => /usr/local/llvm14/lib/libclang.so.13

So l ended up with no -lclang.14 in ldconfig and llvm14 things use /usr/local/llvm13/lib/libclang.so.13 .

In case it is unclear: having all 3 llvm's around at the same time is deliberate and the port's are not designed to share each other's files, even when there is ABI compatibility. ABI compatibility need not imply functionally identical in all observable respects.

[dileks]

@markmi

Looks like you edited your original posting.

I asked @tstellar to clarify on these ABI changes listed in [0] via PM (link in [1] is what you had in the original posting).

Update: [0] was the link I mentioned via PM. So this about clang and libcxx - cannot say what is with libclang.so.

[0] https://releases.llvm.org/14.0.0/tools/clang/docs/ReleaseNotes.html#abi-changes-in-clang
[1] https://releases.llvm.org/14.0.0/projects/libcxx/docs/ReleaseNotes.html#abi-changes

[markmi]

Yea, libclang is not part of libc++ and so I deleted my mistaken reference. As for [0], the libclang section of the page ( https://releases.llvm.org/14.0.0/tools/clang/docs/ReleaseNotes.html#libclang ) is empty, indicating no C ABI change for accessing clang functionality. But that does not mean that using the C interface to clang results in functionally identical behavior in all observable respects, since the clang code has actually changed some compared to 13. The ldconfig -r handling can not pick out 13's functionality vs. 14's functionality. (But can pick out 12's functionality.)

https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#libclang does report "Make libclang SONAME independent from LLVM version. It will be updated only when needed." but actually changed 12->13. 14.0.0 is the first no-change example. https://lists.llvm.org/pipermail/cfe-dev/2021-June/068423.html reported:

This change will allow operating system maintainers to update the version
of libclang.so in their operating system without forcing rebuilds of
all programs that depend on it.

However, that can lead to functional changes in behavior where mixing old and new could be a problem --even though the C code would run.

[kloczek]

So is it bug or feature? 🤔

[kloczek]

Just checked one thing:

[tkloczko@devel-g2v tmp]$ objdump -x libclang.so.14.0.0 libclang-cpp.so.14.0 |grep SONAME
  SONAME               libclang.so.13
  SONAME               libclang-cpp.so.14.0

In other words file name ins case of libclang.so.14.0.0 do not match with SONAME.

Issue is that of distributions which have packaged both clang 14.x and 13.x package manager dependencies resolver is totally confused and it causes that clang 14.x main subpackage with executables will be installed with subpackage with packaged clang 13.x libraries 🤔

As release notes poins that clang 14.x have some ABI changes not changeing main clang library SONAME is IMO bug. and it would be good if someone from LLVM core devel team would confirm that and perepare JFDI commit to fix that.

As LLVM 14.0.1 has alredy many issues which are causing that literally none of the leading distributions in its devel versions decided to move to LLVM 14.0.1 IMO it would be good to clean at least few known 14.x issues and make new 14.0.2 release ASAP.

Personally I wold be interested to sort out #54897

[tstellar]

As release notes poins that clang 14.x have some ABI changes not changeing main clang library SONAME is IMO bug. and it would be good if someone from LLVM core devel team would confirm that and perepare JFDI commit to fix that.

The ABI changes are only in the C++ library (libclang-cpp.so) and not in the C library (libclang.so)

[kloczek]

The ABI changes are only in the C++ library (libclang-cpp.so) and not in the C library (libclang.so)

Nevertheless this is causing some packaging issuew which I've described.
clang and llvm libraries are used by only handfull of projects so it is not big deal to rebuild everything what is using llvm/clang SO.

[markmi]

The ABI changes are only in the C++ library (libclang-cpp.so) and not in the C library (libclang.so)

I'll quote https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Compatibility.html#Compatibility on the type of issue:

QUOTE
compatibility
Conformance to the same ABI and the same behavior of implementation-defined features are both relevant for compatibility.
END QUOTE

[gpakosz]

@h-vetinari There is a libclang.so.14.0.0 symlink you can link against if you need a versioned so name.

@tstellar On Arch Linux, I have

$ /sbin/ldconfig -p | grep clang
        libclang.so.13 (libc6,x86-64) => /usr/lib/libclang.so.13
        libclang.so (libc6,x86-64) => /usr/lib/libclang.so
        libclang-cpp.so.14 (libc6,x86-64) => /usr/lib/libclang-cpp.so.14
        libclang-cpp.so (libc6,x86-64) => /usr/lib/libclang-cpp.so

There's no libclang.so.14 nor libclang.so.14.0.0 symlink. Is it an Arch Linux packaging problem or an upstream problem?

[h-vetinari]

I think this can be considered fixed by bc39d7b.