[gentoo-dev] [RFC] Un-slotting LLVM

[gentoo-dev] [RFC] Un-slotting LLVM

[Michał Górny]

Hi,

A few years back I've slotted LLVM and Clang to make the life with
revdeps easier.  Long story short, every major LLVM release (which
happens twice a year) breaks API and it takes some time for revdeps to
adjust.  Slotting made it possible to install multiple versions
simultaneously, and therefore let "faster" packages use newer LLVM
without being blocked by "slower" packages on the user's system.

Unfortunately, this ended up pretty bothersome to maintain.  Besides
making ebuilds quite complex (and prone to mistakes), I'm hearing more
and more reports of programs being broken through getting multiple LLVM
versions in the link chain.

This is not something that can be easily solved.  In other words, it's
a mess and I don't think we're really getting anywhere.  For this
reason, I'm considering dropping slotting and going back to permitting
only a single version of LLVM and Clang being installed.

This would have two major implications:

1. If you installed any package that requires older LLVM, it'd block all
other packages from updating.  If you hit two packages that do not have
a common supported LLVM version, you won't be able to install them
at all.

On the plus side, this will motivate developers to actually start fixing
these packages rather than letting them rot until I start removing old
LLVM versions.

2. We will no longer support having multiple clang versions installed. 
While it was convenient for testing stuff, it's not really a killer
feature though.

The only real alternative I see is actively limiting supported LLVM
versions in packages to ensure that all libraries in the depgraph end up
using the same LLVM version.  However, I don't think it's really worth
the effort.

I don't have a ready unslotting plan yet.

WDYT?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Un-slotting LLVM

[Florian Schmaus]

On 08/11/2021 12.18, Michał Górny wrote:
> WDYT?

I like slotted LLVM (and GCC) and always find it an advantage over other 
distributions where it is not so easy to install multiple versions of 
LLVM (and GCC). It would be unfortunate to see this go. I also can not 
remember when I last had problems with simultaneously installed LLVM 
versions as a user.

Furthermore, un-slotting LLVM would mean that 
dev-util/include-what-you-use (IWYU) users are bound to the LLVM version 
used by IWYU. Which, in turn, means that they are also bound to the 
corresponding clang-tidy version. Sure, this is nothing that can not be 
solved by manual user intervention, e.g., users manually installing a 
newer clang-tidy version. But still, it would not be as easy and 
convenient as before.

That said, I think it's mostly, if not wholly, up to the maintainer. And 
since you already do a lot of Gentoo work, it may also be a win if we 
reduce your LLVM workload.

- Flow

Re: [gentoo-dev] [RFC] Un-slotting LLVM

[Luke A. Guest]

This would stop other projects from working where they have their own 
llvm port, cough rocm cough.

On 08/11/2021 11:18, Michał Górny wrote:
> Hi,
> 
> A few years back I've slotted LLVM and Clang to make the life with
> revdeps easier.  Long story short, every major LLVM release (which
> happens twice a year) breaks API and it takes some time for revdeps to
> adjust.  Slotting made it possible to install multiple versions
> simultaneously, and therefore let "faster" packages use newer LLVM
> without being blocked by "slower" packages on the user's system.
> 
> Unfortunately, this ended up pretty bothersome to maintain.  Besides
> making ebuilds quite complex (and prone to mistakes), I'm hearing more
> and more reports of programs being broken through getting multiple LLVM
> versions in the link chain.
> 
> This is not something that can be easily solved.  In other words, it's
> a mess and I don't think we're really getting anywhere.  For this
> reason, I'm considering dropping slotting and going back to permitting
> only a single version of LLVM and Clang being installed.
> 
> This would have two major implications:
> 
> 1. If you installed any package that requires older LLVM, it'd block all
> other packages from updating.  If you hit two packages that do not have
> a common supported LLVM version, you won't be able to install them
> at all.
> 
> On the plus side, this will motivate developers to actually start fixing
> these packages rather than letting them rot until I start removing old
> LLVM versions.
> 
> 2. We will no longer support having multiple clang versions installed.
> While it was convenient for testing stuff, it's not really a killer
> feature though.
> 
> The only real alternative I see is actively limiting supported LLVM
> versions in packages to ensure that all libraries in the depgraph end up
> using the same LLVM version.  However, I don't think it's really worth
> the effort.
> 
> I don't have a ready unslotting plan yet.
> 
> WDYT?
> 

Re: [gentoo-dev] [RFC] Un-slotting LLVM

[Gerion Entrup]

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]

Am Montag, 8. November 2021, 12:18:30 CET schrieb Michał Górny:
> WDYT?

Not a Gentoo dev but a user who develops software.
I find it pretty convenient to have multiple LLVM versions available.
I'm developing software that links against LLVM and can test it against
multiple versions pretty easy with the current setup. I can evaluate a
new LLVM version before switching my own software to it. I can even test
some old (already bit-rotted) software that needs an old LLVM version since
Gentoo provides it.

I'm pretty sure that this argument also holds for all users that want to
test their software against multiple versions of Clang (just the same as it
holds for slotted GCC).

To summarize: Slotted LLVM is not only a feature for other distribution
packages but also for users of Gentoo that develop software in compiled
languages.


> I'm hearing more
> and more reports of programs being broken through getting multiple LLVM
> versions in the link chain.

I'm actually experienced this, but slotted LLVM was a solution here not
a problem. Let me explain the link chain (an arrow means: "link against"):

my tool --> an unpackaged third party lib (bound to an old LLVM) -> LLVM 10
        ´-> graph-tool -> matplotlib -> Mesa (with AMD graphic card) -> LLVM 12 (system default)

So my tool depends on a third party lib which needs LLVM 10 (without an easy port).
But as I also have an AMD graphic card so my Mesa is compiled with libLLVM for AMDGPU
which loads LLVM 12. My tool uses graph-tool which at the end loads Mesa.
As a result my LLVM versions conflicted.

My fix was to modify the Mesa ebuild to use LLVM 10 as well. This would
have been possible without slotted LLVM, but then I has to use LLVM 10
for everything in my system. I'm also not sure, if this would
be possible on any other distribution (without containerizing stuff).
(In the meantime the third party lib has updated its code to LLVM 12 so
everything is fine again.)

Best,
Gerion

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [gentoo-dev] [RFC] Un-slotting LLVM

[Georgy Yakovlev]

On 08.11.2021 12:18, Michał Górny wrote:
> Hi,
> 
> A few years back I've slotted LLVM and Clang to make the life with
> revdeps easier.  Long story short, every major LLVM release (which
> happens twice a year) breaks API and it takes some time for revdeps to
> adjust.  Slotting made it possible to install multiple versions
> simultaneously, and therefore let "faster" packages use newer LLVM
> without being blocked by "slower" packages on the user's system.
> 
> Unfortunately, this ended up pretty bothersome to maintain.  Besides
> making ebuilds quite complex (and prone to mistakes), I'm hearing more
> and more reports of programs being broken through getting multiple LLVM
> versions in the link chain.
> 
> This is not something that can be easily solved.  In other words, it's
> a mess and I don't think we're really getting anywhere.  For this
> reason, I'm considering dropping slotting and going back to permitting
> only a single version of LLVM and Clang being installed.
> 
> This would have two major implications:
> 
> 1. If you installed any package that requires older LLVM, it'd block all
> other packages from updating.  If you hit two packages that do not have
> a common supported LLVM version, you won't be able to install them
> at all.
> 
> On the plus side, this will motivate developers to actually start fixing
> these packages rather than letting them rot until I start removing old
> LLVM versions.
> 
> 2. We will no longer support having multiple clang versions installed. 
> While it was convenient for testing stuff, it's not really a killer
> feature though.
> 
> The only real alternative I see is actively limiting supported LLVM
> versions in packages to ensure that all libraries in the depgraph end up
> using the same LLVM version.  However, I don't think it's really worth
> the effort.
> 
> I don't have a ready unslotting plan yet.
> 
> WDYT?
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

This can block rust and consumers quite badly.
Currently in rust source ebuild we lock llvm version for system llvm to
exact one bundled by upstream, for example

1.55 - llvm12 (with/without system-llvm set)
1.56 - llvm13 (with/without system-llvm set)

that's effective with both system-llvm set or unset, and for rust-bin.
in theory I can unlock rust version and provide compatibility with
multiple, but we run into next problem:

rust-1.56 can come with llvm12 and llvm13, but only llvm13 if -system-llvm
rust-bin only can use llvm13 (internal one, pre-compiled by upstream)

this will break firefox and spidermonkey and thunderbird on some
systems.
mozilla products need to be compiled and linked with the same llvm
version in all components. 

compiling/linking firefox with llvm13/clang13, but rust-1.55 will
not be possible, because of mis-matched llvm versions. or it may work
but break at runtime.

and if we have multiple llvm possible in firefox it will not be able to
enforce dependency chain via portage.

well, we could introduce llvm-ver useflags for rust, and clang, so
firefox can require rust[llvm13(-)] clang[llvm13(-)] with a lot of
required-use boilerplate, but that's _very_ ugly.

-- 
Best regards,
Georgy

Re: [gentoo-dev] [RFC] Un-slotting LLVM

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]



> On 8 Nov 2021, at 11:18, Michał Górny <mgorny@gentoo.org> wrote:
> Hi,
> A few years back I've slotted LLVM and Clang to make the life with
> revdeps easier.  Long story short, every major LLVM release (which
> happens twice a year) breaks API and it takes some time for revdeps to
> adjust.  Slotting made it possible to install multiple versions
> simultaneously, and therefore let "faster" packages use newer LLVM
> without being blocked by "slower" packages on the user's system.
> 
> Unfortunately, this ended up pretty bothersome to maintain.  Besides
> making ebuilds quite complex (and prone to mistakes), I'm hearing more
> and more reports of programs being broken through getting multiple LLVM
> versions in the link chain.

I think this might just be Blender and friends which are especially fragile.

We may be able to get away with just coordinating those together.

> WDYT?

If we can help it, I'd really really prefer we don't. Being able to test
various different various of Clang quickly (just like gcc) is really helpful.

(especially given one day, we might dare to dream of using Clang
for the system toolchain. It becomes a lot easier to check for
regressions if you can just flip the version.)

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Un-slotting LLVM

[James Beddek]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Tuesday, 9 November 2021 2:41:53 PM NZDT Sam James wrote:
> > On 8 Nov 2021, at 11:18, Michał Górny <mgorny@gentoo.org> wrote:
> > Hi,
> > A few years back I've slotted LLVM and Clang to make the life with
> > revdeps easier.  Long story short, every major LLVM release (which
> > happens twice a year) breaks API and it takes some time for revdeps to
> > adjust.  Slotting made it possible to install multiple versions
> > simultaneously, and therefore let "faster" packages use newer LLVM
> > without being blocked by "slower" packages on the user's system.
> > 
> > Unfortunately, this ended up pretty bothersome to maintain.  Besides
> > making ebuilds quite complex (and prone to mistakes), I'm hearing more
> > and more reports of programs being broken through getting multiple LLVM
> > versions in the link chain.
> 
> I think this might just be Blender and friends which are especially fragile.
> 
> We may be able to get away with just coordinating those together.
> 
> > WDYT?
> 
> If we can help it, I'd really really prefer we don't. Being able to test
> various different various of Clang quickly (just like gcc) is really
> helpful.
> 

I agree. Personally, it's allowed me to narrow down a few bugs in programs/
test suites which only occur with specific LLVM/Clang versions. While I could 
just build the different versions locally, slotting in combination with 
package.env really has made testing easier.

> (especially given one day, we might dare to dream of using Clang
> for the system toolchain. It becomes a lot easier to check for
> regressions if you can just flip the version.)
> 

I'd love to see this one day :-)

> Best,
> sam


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] Un-slotting LLVM

[Michał Górny]

On Mon, 2021-11-08 at 12:18 +0100, Michał Górny wrote:
> Hi,
> 
> A few years back I've slotted LLVM and Clang to make the life with
> revdeps easier.  Long story short, every major LLVM release (which
> happens twice a year) breaks API and it takes some time for revdeps to
> adjust.  Slotting made it possible to install multiple versions
> simultaneously, and therefore let "faster" packages use newer LLVM
> without being blocked by "slower" packages on the user's system.
> 
> Unfortunately, this ended up pretty bothersome to maintain.  Besides
> making ebuilds quite complex (and prone to mistakes), I'm hearing more
> and more reports of programs being broken through getting multiple LLVM
> versions in the link chain.
> 
> This is not something that can be easily solved.  In other words, it's
> a mess and I don't think we're really getting anywhere.  For this
> reason, I'm considering dropping slotting and going back to permitting
> only a single version of LLVM and Clang being installed.
> 
> This would have two major implications:
> 
> 1. If you installed any package that requires older LLVM, it'd block all
> other packages from updating.  If you hit two packages that do not have
> a common supported LLVM version, you won't be able to install them
> at all.
> 
> On the plus side, this will motivate developers to actually start fixing
> these packages rather than letting them rot until I start removing old
> LLVM versions.
> 
> 2. We will no longer support having multiple clang versions installed. 
> While it was convenient for testing stuff, it's not really a killer
> feature though.
> 
> The only real alternative I see is actively limiting supported LLVM
> versions in packages to ensure that all libraries in the depgraph end up
> using the same LLVM version.  However, I don't think it's really worth
> the effort.
> 
> I don't have a ready unslotting plan yet.
> 
> WDYT?
> 

I've got the message and slotted LLVM and Clang are going to stay for
the time being.

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: [RFC] Un-slotting LLVM

[Benda Xu]

Hi Michał,

Michał Górny <mgorny@gentoo.org> writes:

>> [...]
>>
>> Unfortunately, this ended up pretty bothersome to maintain.  Besides
>> making ebuilds quite complex (and prone to mistakes), I'm hearing more
>> and more reports of programs being broken through getting multiple LLVM
>> versions in the link chain.
>> 
>> This is not something that can be easily solved.  In other words, it's
>> a mess and I don't think we're really getting anywhere.  For this
>> reason, I'm considering dropping slotting and going back to permitting
>> only a single version of LLVM and Clang being installed.
>> 
>> [...]
>
> I've got the message and slotted LLVM and Clang are going to stay for
> the time being.

Thank you!  I appreciate your decision.  From the discussions of this
thread, the quality and SLOTing of llvm is a killing feature of Gentoo.

Shall we open a tracker bug to put together the linkage bugs?  We might
gain some inspirations from the global picture.

Yours,
Benda