it happens in the past and may happen in the future that new features are added to llvm / clang tblgen program. When this happens, llvm / clang would not be able to merge using the previous version of [llvm|clang]-tblgen tool. This can quite easily be avoided in all cases by always using the bundled version of tblgen for the package we are currently compiling. Reproducible: Sometimes Steps to Reproduce: 1. Try to update llvm / clang 2. May fail because of missing features in previous tblgen version 3. The bug has not been seen while merging recent versions has I did apply this patch since transition from 9.x to 10.x version. Then, this would be more to prevent eventual bugs in any case in the future
Created attachment 849552 [details, diff] Patch to llvm ebuild to always use bundled llvm-tblgen version
Created attachment 849553 [details, diff] Patch to sys-devel/clang ebuild to always use bundled clang-tblgen tool
Are you saying that this can happen even when you're not cross-compiling? I highly doubt that. Obviously a native build has to work without LLVM already being installed the first time. Even if you do only mean when cross-compiling, this isn't needed from 16.0 onwards, because it automatically uses a fresh llvm-tblgen build for you. I doubt 14.0 or 15.0 are going to break now that 16.0 is nearly ready.
it did happen in the past when not cross-compiling as new features were added to llvm-tblgen, if I remember well, and the previous version was then not able to generate tables for the new version to be installed. I do not remember the versions were this happened and cannot tell if it happened after I had the problem as I got this patch applied since then for llvm and clang. In every case, it seems to me safer to use the bundled version of xxx-tblgen tool instead of relying on potentially to old or bugged (in case of bugfixes been applied in the while) version.
(In reply to Jocelyn Mayer from comment #4) > > In every case, it seems to me safer to use the bundled version of xxx-tblgen > tool instead of relying on potentially to old or bugged (in case of bugfixes > been applied in the while) version. But that's not going to happen given it builds a fresh copy now?
I'm not sure I understand well what you mean there: if you mean that it would not happen when using the bundled version, then I agree and that is the exact reason of this proposal. If ever the xxx-tblgen bundle version cannot build llvm and / or clang, then this would mean the release is bugged and would not be safe to use. ... which does not mean, of course, that the bundled tblgen being safe or usable makes the whole package safe !
OK, I guess I understood: I always compile llvm / clang in multilib environments, then always reach the "cross-compiling" case, isn't that right ?
Regular multilib does not count as cross-compiling, so no, that doesn't apply. If you're using the other non-standard kind of multilib that I've forgotten the name of, then you're on you're own. What we're saying is that from 16.0, even when cross-compiling, it would always use the "bundled" version. Look at the 16.0 ebuilds. There is no -DLLVM_TABLEGEN line there. Even with 15.0.7, a native build also uses the bundled version. I tried symlinking my existing llvm-tblgen to /bin/false and succeeding in doing a fresh build. I could see from the log that it was only trying to use the bundled version. This could hypothetically happen with 14.0 and 15.0 when cross-compiling, but it seems highly unlikely. I would sooner say "update the build host" or "just use 16.0" than make this even more complicated.
well, it seems that LLVM version 16 is still a release candidate so "update to version 16" cannot be an option for any stable machine as for now, even less for hardened ones... Checking the ebuilds, it happens that the bundled llvm-tblgen version seems, as previously said, to always be implicitelly used it is not the case for clang-tblgen from what can be seen even from the 16 rc version. The said "could hypothetically happen ... when cross-compiling" seems incorrect here. It is obvious that if ever a new feature is added to one of the tblgen tools, it would be impossible to generate files for the new version using the tblgen tools from the previous version. This is not hypothetical as it did happen in the past, at least for one version, even not when cross-compiling....
But Chewi says: >Even with 15.0.7, a native build also uses the bundled version. I tried >symlinking my existing llvm-tblgen to /bin/false and succeeding in doing a >fresh build. I could see from the log that it was only trying to use the >bundled version.
well, I'm wrong, sorry I missed this part...
