https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- >> --- Comment #12 from Petr Sumbera <sumbera at volny dot cz> --- >> (In reply to Petr Sumbera from comment #9) >>> (In reply to r...@cebitec.uni-bielefeld.de from comment #8) >>> > > without the JIT patch (033-solaris-LLVM-JIT.patch)? It may be worth a >>> > > try >>> > > until someone fixes and integrates SPARC JIT support for real. >>> >>> I will try to build LLVM without the patch and will see. But the patch says >>> it >>> was created because of gnome-shell. >> >> When I updated test system with LLVM built without 033-solaris-LLVM-JIT.patch >> (without rebuilding any other component) it fails in different way (probably >> earlier). See bellow. I think that the patch is really needed. > [...] >> libLLVM-13.so`_ZN4llvm14RuntimeDyldELF23resolveX86_64RelocationERKNS_12SectionEntryEmmjlm+0x64(969a060b00?, >> 9699f673c0?, 20?, 7af3bfb12000?, 18?, 0?) > > Seems so. Calling llvm::RuntimeDyldELF::resolveX86_64Relocation on a > SPARC ELF file is obviously complete bullshit. Might be something > already fixed in newer LLVM versions. Somehow, the architecture > detection is amiss... That's almost certainly due to Solaris still including LLVM 13, which is pretty old by now. In particular, it lacks llvm::sys::getHostCPUName. My patch to implement this on SPARC only landed in LLVM 16. > However, given my impression from the mesa code is that even a proper > error handling in RuntimeDyLD wouldn't help there. Mesa uses the same function, so this may well be a second instance of the same problem.
