llvm21: drop libcxx and libunwind options (now part of llvm22)

[JkktBkkt]

Testing the changes

• I tested the changes in this PR: briefly — successfully built gifski and pwmenu via x86_64, x86_64-musl and i686 using rebuilt clang21

Local build testing

• I built this PR locally for my native architecture, x86_64
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • x86_64-musl
  • i686
  • armv6l
  • armv6l-musl
  • armv7l
  • armv7l-musl
  • aarch64
  • aarch64-musl

Closes #61005

I'm unsure if the revbump is necessary, there should be no functionality change from this, and this is addressing one of the roadblocks encountered in #59704

Based on bbdaa35 but I did not remove the lldb python integration.

[ci skip]

[Duncaen]

This doesn't need a rebuild.

[Duncaen]

I think it would make sense to just disable the build options instead of removing all the code.

[JkktBkkt]

Builds like this, after enabling libunwind and libcxx as runtimes, otherwise runs into

=> clang21-headers-21.1.7_1: running pkg_install ...
mv: cannot stat '/destdir//llvm21-21.1.7/usr/lib/llvm/21/include/c++': No such file or directory

void-packages/srcpkgs/llvm21/template

Line 637 in 529624a

vmove "${_llvm_incdir}/c++"

Converted to draft: am going to run builds on other archs (including cross) and a test build.

[JkktBkkt]

Same testing done as in description, all went fine

[Duncaen]

Isn't it enough to just change the default build options instead of unconditionally enabling the runtimes?

[JkktBkkt]

Unfortunately not, that's what I tried first a few months ago (and again before finding commit by ahesford).
Build works but it then fails in packaging step.

#61029 (comment) has log snippet from running with just the -o ~libunwind,~libcxx added in a test build on master

[ahesford]

I'd rather see the vestigial build options and supporting logic removed. Changing the default build options or removing them from the list of options obfuscates the fact that the template is unable to build should that option be enabled by an unsuspecting user. It's better to eliminate these dead bits of the template.

[Duncaen]

I think its better to have a switch that can be turned off, there shouldn't be a guess what can be removed and what changes are require to the template or the resulting packages.

It doesn't even have to be just build options defaults, you could remove it from build_options then it can't be enabled.

There are some issues with how libcxx is build and installed multiple times, which should probably be fixed.

Other than that, would probably even better if we just moved the runtimes out of the versioned llvm packages, but there might be issues with build cycles where llvm components may link the runtimes and the runtimes may need to be build with the latest llvm.