stefson

update with your new implementation: `clang -print-multiarch` gives `arm-linux-musleabihfeabi` yikes :D I did the backport to clang-13 myself, there was a conflict with a riscv specific patch merged in 15.x...

@listout emerging clang-13 again with patch v3 from: https://github.com/listout/llvm-project/commit/efa625a7b809f1ccae921d36cd8601a8fca57b3c

@listout I restarted the ongoing emerge with the patch you posted - where are you two coordinating your efforts? its not in the llvm bug or here, thats for sure.

@listout with the linked patch it seems to work now: `clang -print-multiarch` gives `arm-linux-musleabihf` 🥳

@listout my test was done with clang-13 ; arm is so slow I was unable to spend enough cpu time for upgrading the llvm toolchain to slot 14 yet. If...

that gives me the same output on stock amd64 clang-14.0.6-r1: `clang-14 -target arm-gentoo-linux-gnu -print-multiarch` gives `arm-linux-gnueabi`

@listout what is the status of this, please? Another user commented in https://bugs.gentoo.org/862888 that this is solved with clang-15.0.0 final, is this correct and therefore your patches were rejected?

I keep hitting the same linking error, is there no nuclear option to disable all of openal through cmake?

fisherman was always good for a crash, but I haven't encountered any of them for a very long time now.

recently I tried to upgrade the kernel of my rpi2 using gcc-9.3.0 and glibc-2.31 in the cross compile toolchain, and I believe to have hit a similar issue. Can't say...