Unresolved issues from the LLVM 15.x release

AFAIU all that’s necessary is fetching both the llvm & the cmake tarballs and unpacking them in the same folder, then build the llvm folder.

I’m not talking about fetching tarballs, but rather about importing llvm (via e.g. git subtree) into downstream repo. The top-level cmake folder should be imported as well and it might be in quite strange place.

Haven’t used git subtree, but I can’t see why it wouldn’t be possible to do that twice (all that should be necessary is putting llvm/ and cmake/ in the same folder)?

For what it’s worth, in Chromium we’re still struggling with test failures after D132438 relanded. I’m not sure why these problems aren’t being caught upstream.

Thanks, will do.

15.0.1 and up have downgraded this back into an on-by-default warning (rather than a warning that defaults to an error), so for 15.x, I think we’re good.

For 16.x, the current behavior is that they are warnings which default to an error. My understanding is that @mgorny and others have been diligently working through the fallout and have been making good progress on fixing up things from their side. So I’m relying on distro folks to speak up if we’re still not in a good enough place to be able to leave the diagnostics as defaulting to an error, but I figured we’d see where things stand as we get closer to the branch point for 16.0.0.

It doesn’t work. Left a comment in Should buildbots switch to ENABLE_RUNTIMES instead of ENABLE_PROJECTS for compiler-rt? - #10 by hansw2000

Bumping this topic again so we have a less “hair-on-fire” situation when dealing with this than last time. :sweat_smile:

My preference would be to default to have a separate SOVERSION for libclang that only changes when actually necessary, along the lines of the original RFC.

This would however represent the third(!) change of default in as many LLVM releases, and I can understand that people would be reluctant to do so (though I noted already for the reversion of the default for LLVM 15 that we’d find ourselves in this situation…)

LLVM version libclang SOVERSION Comment
13 13 and before, situation pre-RFC
14 13 RFC accepted
15 15 Default reverted to pre-RFC; switch available to keep RFC
16 ? Re-apply RFC?

The reason I left a question-mark in the table is that I think a deficiency of the original approach was to use a numbering scheme which made it look like a bug (i.e. someone forgot to bump 13->14). I think if there were a separate libclang versioning scheme that looks less like it should be 1:1 with the LLVM version (whether that’s restarting from 1, adding 1000 to LLVM version[1], or whatever), this would help get rid of the confusion with a separate SOVERSION, and would still let people that are affected by ABI benefit from the fact that there’s now less things to rebuild.


  1. those that change the libclang ABI; the idea of the RFC was to reset the libclang SOVERSION to the current LLVM version whenever the ABI changes, meaning we’d continually run into the “looks like someone forgot to bump the version” issue. ↩︎

1 Like

Ping @tstellar @tobiashieta @sylvestre @mgorny @daphnediane @aaronpuchert

I don’t have a strong opinion as long as it can be switched to matching SOVERSION but I’d like to note that this is a dangerous default when linking to shared LLVM libraries / dylibs.

Unless I’m mistaken, the other option is “inefficient” at best (i.e. requiring you to rebuild more often), so I’m not convinced putting the users at risk is worth it. If you change the default, then at the very least you should warn if LLVM_LINK_LLVM_DYLIB is enabled along with the SOVERSION option — or perhaps we should do that anyway.

Given that the version number would change (by definition, up to bugs) when the ABI does, what dangers do you see for this?

Quoting some (IMO) relevant context from the previous thread:

Ah, sorry, I thought I’ve already said it but I guess it was in another thread. Let’s say that a program links both to libclang.so.X and libLLVM-Y.so. Now LLVM gets upgraded — this means that a new SOVERSION of libLLVM-Z.so is installed but libclang.so.X gets replaced if it didn’t change the ABI. Effectively, the program is now linking to new libclang.so.X and old libLLVM-Y.so, effectively getting both libLLVM-Y.so and libLLVM-Z.so loaded.

This is a real problem for many Linux distributions. LLVM makes breaking API changes with every major release, and many programs find it very hard to keep up. We have to support installing multiple LLVM versions simultaneously, and therefore we also need to be able to install different versions of libclang.so that link to a specific release of LLVM.

1 Like

Are you sure about that? On Linux we use symbol versions, so the symbols would use either version LLVM_Y or LLVM_Z and thus not collide. I’m not aware of any issues with loading multiple versions of libLLVM.so into the same process. (Not anymore, it used to be an issue before we started using symbol versions in LLVM 5.)

We also got complaints about that unfortunately: see the discussion on issue 53281 after it was closed. (All LLVM 14 tarballs had the bundled cmake directory.) Seems there is no way to make everyone happy.

I’m not sure. I think I’ve seen reports of that relatively recently but I may be wrong. I have a bad feeling that the command-line option logic may explode.

Unfortunately, I don’t have any package using libLLVM-*.so + libclang.so handy. I could try to find some and do some testing but I’m not sure if and when I’ll have sufficient time to do that.

Where I’ve had issues was with KDevelop. That uses libclang.so directly and if you’re using Mesa, it uses libLLVM.so through that. Otherwise, directly using both libraries is probably rare, after all one of the selling points of libclang.so is the stable interface.

Have we reached a conclusion here? (As a reminder, the branch date is Jan 24.)

Do you think this is resolved for Clang 16 or is there something more to be done here?

@mgorny or others, are you satisfied with the state of things for Clang 16 for implicit function declaration diagnostics?

I’m as happy as I can be w/ the Clang side of things. In an ideal world, we’d wait a year or two more, but I know you don’t want to do that, and it’s not a realistic ask. I’m not sure if I truly want that anyway because you can’t punt it forever.

Plus, at a point, I think the world needs to see the problem and no amount of screaming from a small group of people will help anyway (the only tangible thing that would be nice to have before 16 is an autoconf release, but that’s a work in progress). I don’t think we’re at that position just yet, but it’s why I’m not going to bother arguing for a delay of N more releases, because there’s diminishing returns.

The situation is still not-great out in the wild but we’ve upstreamed a lot of fixes and @fweimer-rh is working on it from the Fedora side now too. It’s better than it was 6 months ago and we’ve had time to work on documentation, spread the word, and get people working on it.

In Gentoo, we’re no longer at “total disaster” and now at “oh god there’s a lot of work to do” and that’s an okay place to be in for a change of this scale. I’m glad we punted it to 16 and it bought us a lot of time to start the ball rolling on this.

TL;DR: Grumblings about lots of work to be done in the ecosystem, but I don’t think there’s anything specific LLVM needs to address, unless you decide you want to wait a year or two. The situation is a definite improvement on 6 months ago.

1 Like

Thank you for the feedback and all of the discussion on this, and sorry (again) for the troubles. We’ll keep things as-is for Clang 16 unless we get more feedback after the RC goes out.

1 Like