ROOT 6.26/04 fails to build with LLVM/Clang 14.0.6 with C++17 / libc++ on SLF7
#10861
Closed
1 task done
Assignees
Labels
affects:master
affects:6.26
affects:6.28
bug
experiment
Affects an experiment / reported by its software & computimng experts
in:Build System
in:C++ modules
priority:default
Comments
greenc-FNAL
added
bug
in:Build System
in:C++ modules
affects:6.26
experiment
|
Is there any chance to get the backtrace with some more debug info from the llvm side, by adding |
|
Should be relatively straightforward. Working on it now. |
|
Sorry for the slow response from me! To make things worse, it's highly asymmetrical: thanks for your super fast reaction :-) |
|
I'm on vacation for the next week, but I'll try to provide whatever extra information you can tell me you need today ASAP. Log file with |
|
@vgvassilev FYI: Please lmk if you have any indication what could cause this. @chissg thanks a lot, that's super helpful (and very unexpected). |
|
Does LLVM/Clang 14.0.6 / libc++ introduce additional stdlib modules? |
How would I find out? |
|
I am hoping that @vgvassilev will either know of be able to tell us what to look for (likely something |
|
Which is the failing submodule? |
|
@vgvassilev how would I ascertain that? Attached: result of |
|
@vgvassilev not sure what you expect here - gdb doesn't print I've lowered this to "default priority" because it likely affects only current libc++ - and that's a very rare environment. We cannot block 6.26/06 because of this issue. |
|
Bump? |
|
Apologies for the delay. Can you apply that patch and see which is the output it currently fails upon: diff --git a/interpreter/llvm/src/tools/clang/lib/Serialization/ASTWriter.cpp b/interpreter/llvm/src/tools/clang/lib/Serialization/ASTWriter.cpp
index 3829014415..e4a2fab675 100644
--- a/interpreter/llvm/src/tools/clang/lib/Serialization/ASTWriter.cpp
+++ b/interpreter/llvm/src/tools/clang/lib/Serialization/ASTWriter.cpp
@@ -2789,11 +2789,12 @@ unsigned ASTWriter::getLocalOrImportedSubmoduleID(Module *Mod) {
return SubmoduleIDs[Mod] = NextSubmoduleID++;
}
-
+extern "C" int printf(const char*,...);
unsigned ASTWriter::getSubmoduleID(Module *Mod) {
// FIXME: This can easily happen, if we have a reference to a submodule that
// did not result in us loading a module file for that submodule. For
// instance, a cross-top-level-module 'conflict' declaration will hit this.
+ printf("Submodule=%s\n", Mod->Name.c_str());
unsigned ID = getLocalOrImportedSubmoduleID(Mod);
assert((ID || !Mod) &&
"asked for module ID for non-local, non-imported module");I need to remember how to reproduce your setup and I could be more helpful... |
|
Sorry for the radio silence on this: other priorities took over and this wasn't a showstopper at the time. I have just verified the same failure with 66df8b8, and will apply the suggested patch to that and see where we get to. |
|
(Patch applied with offset) |
|
@vgvassilev @Axel-Naumann Report: no-one called |
|
Correction: |
|
It appears that the patch was not applied or overwritten. Checking... |
|
I'd uploaded the wrong log file to the issue. Here it is: |
|
Here it tells us that it loads the default modulemap of libcxx: I will debug why this fails for 6.28. |
I did not update my container to the last update of yours. I just restarted it and used the same approach for Now what's wrong with |
|
I have managed to pinpoint the reasons for the difference in behavior:
--- interpreter/llvm/src/tools/clang/lib/Serialization/ASTWriter.cpp~ 2023-01-10 11:09:06.666075151 -0600
+++ interpreter/llvm/src/tools/clang/lib/Serialization/ASTWriter.cpp 2023-01-10 11:34:45.644464781 -0600
@@ -105,6 +105,7 @@
#include <algorithm>
#include <cassert>
#include <cstdint>
+#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <ctime>
@@ -2498,6 +2499,8 @@
// did not result in us loading a module file for that submodule. For
// instance, a cross-top-level-module 'conflict' declaration will hit this.
unsigned ID = getLocalOrImportedSubmoduleID(Mod);
+ fprintf(stderr, "Mod=%X\n", Mod);
+ fprintf(stderr, "Submodule=%s\n", Mod->Name.c_str());
assert((ID || !Mod) &&
"asked for module ID for non-local, non-imported module");
return ID;
--- interpreter/llvm/src/tools/clang/lib/Serialization/ASTWriterDecl.cpp~ 2023-01-06 05:04:43.000000000 -0600
+++ interpreter/llvm/src/tools/clang/lib/Serialization/ASTWriterDecl.cpp 2023-01-10 13:21:47.554190854 -0600
@@ -26,6 +26,8 @@
using namespace clang;
using namespace serialization;
+#include <cstdio>
+
//===----------------------------------------------------------------------===//
// Declaration serialization
//===----------------------------------------------------------------------===//
@@ -361,6 +363,8 @@
Record.push_back(D->isTopLevelDeclInObjCContainer());
Record.push_back(D->getAccess());
Record.push_back(D->isModulePrivate());
+ D->dump();
+ if (D->getOwningModule()) fprintf(stderr, "D->getOwningModule()->Name=%s", D->getOwningModule()->Name.c_str());
Record.push_back(Writer.getSubmoduleID(D->getOwningModule()));
// If this declaration injected a name into a context different from itsitself causes issues with dictionary generation. Once removed, compilation succeeds. As for the libunwind issue, I believe https://bugs.llvm.org/show_bug.cgi?id=44074 is illuminative. The LLVM/Clang in use in the Linux Docker container is configured to use |
|
Glad this worked out! There are number of patches proposed. Could you try them out and I can backport a set of them it is confirmed to work for you. I am asking because we are far down the release procedure? |
|
I am relatively well situated to try things out with respect to ROOT's |
|
Yes, that works! |
|
Just verified a successful build of master with our build apparatus. Let me know when you have something to graft on. |
|
So the master has no issue with libunwind but 6.28 has? I don’t think there have been changes in this area but can you bisect which commit “fixes” this issue? |
|
Hi @chissg - I'd very much appreciate if we don't have to hold v6.28/00 for this. We would then try to address this issue in a follow-up patch release for the v6.28 series. Is that okay for you? |
|
Perfectly fine: our usual procedure is to apply the current state of |
Sorry, that's not the meaning I intended to convey! The |
|
Ok, then in that case we should probably try the set of patches mentioned in the bug report you sent. I am happy to backport whatever (sub)set of them which makes your builds happy. |
|
I'll give them a try this morning and let you know. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@mkrzewic no that's different - for FreeBSD, ROOT fails to determine the binary path for the current process. I remember that to be a problem but we don't have a dedicated GitHub issue for it; could you create one, please? |
|
@greenc-FNAL any news on this? |
|
The remaining issues would seem to be related to the way Clang is built for our ecosystem relative to how ROOT's internal Clang is built/configured. It's not urgent right now, and may be mooted by a move to Spack for building all our software (this is still in development). |
So you're not using the builtin clang then? I missed that so far. Are there any patches coming out of this issue that ROOT would need to take care of? |
No, we're using the builtin Clang for Cling. However, the Clang we're using to build everything is configured in a way that is incompatible with the way ROOT's builtin Clang is built. In order to avoid dependency on a non-native GCC on SLF7 we use a bootstrapped build of Clang with
Don't think so. We'll revisit the issue when we're more advanced with our migration from UPS to Spack. |
|
@greenc-FNAL, what is the status here? Maybe our recent upgrade to LLVM 16 resolved the remaining issues? |
|
One more ping, apologies for this. @greenc-FNAL @vgvassilev could we close the item? |
|
I propose to close the item. Since the start of this thread, ROOT and cling improved greatly and SLF7 is approaching its end of life, scheduled for June 30 2024. Please do not hesitate to reopen if you think this is still an issue ROOT needs to address. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
ROOT 6.26/04 (https://github.com/root-project/root/tree/02b2af7af1be3430a3124236a7cdc6bb13cf90d2) fails to build with LLVM/Clang 14.0.6 with the following error from
rootcling:Expected behavior
Successful build.
To Reproduce
Attempt to build ROOT with LLVM/Clang 14.0.6 and C++17 /
libc++(precise configuration should be irrelevant providedruntime_cxxmodulesisON).Additional context
This was a second, simplified attempt after
rootclingfailed to find PSTL headers (e.g.__pstl_memory) in<clang-lib>/clang/14.0.6/includeduring the ROOT build when LLVM/Clang was compiled with parallel algorithms enabled inlibc++.Currently attempting to reproduce onmasterbranch.Fail with identical error on master (https://github.com/root-project/root/tree/7b7983fa8ab9e1a4af98776f7f80bea1f9b2b0b0).
The text was updated successfully, but these errors were encountered: