You are not logged in.
The recent llvm commit 30633f308941 broke mesa trunk building .
I filed https://gitlab.freedesktop.org/mesa/mesa/-/issues/13986 to deal with it, but it looks like a fairly simple change (for clients).
../mesa/src/compiler/clc/clc_helpers.cpp: In function ‘std::unique_ptr<llvm::Module> clc_compile_to_llvm_module(llvm::LLVMContext&, const clc_compile_args*, const clc_logger*, set*)’:
../mesa/src/compiler/clc/clc_helpers.cpp:869:24: error: no matching function for call to ‘clang::CompilerInstance::createDiagnostics(llvm::vfs::FileSystem&, clang::TextDiagnosticPrinter*)’
The code that generates this starts at src/compiler/clc/clc_helpers.cpp line 689
c->createDiagnostics(
#if LLVM_VERSION_MAJOR >= 20
*llvm::vfs::getRealFileSystem(),
#endif
new clang::TextDiagnosticPrinter(
diag_log_stream,
diag_opts));
c->setTarget(clang::TargetInfo::CreateTargetInfo(
#if LLVM_VERSION_MAJOR >= 21
c->getDiagnostics(), c->getInvocation().getTargetOpts()));
#else
c->getDiagnostics(), c->getInvocation().TargetOpts));
#endif
c->getFrontendOpts().ProgramAction = clang::frontend::EmitLLVMOnly;
Building with llvm 22+ requires mesa to create the vfs explicitly and then use it in the creatediagnostics call.
Writing a solution using pseudocode should be doable for me, but I am way below the skill level needed to convert that to actual code.
Please help.
Last edited by Lone_Wolf (2025-10-04 08:51:32)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Building with llvm 22+ requires mesa to create the vfs explicitly and then use it in the creatediagnostics call.
Writing a solution using pseudocode should be doable for me, but I am way below the skill level needed to convert that to actual code.Please help.
Interesting, possibly the API changed and it's yet to reflect on mesa?
Anyways, vfs is available to userspace? Maybe via fuse, it this what is going on?
Offline
The vfs referred to seems to be for outputting client diagnostic messages so is probably temporary and only accessible to client and compiler runtime libs.
Clang changed the method used several times, first time mesa had to do make vfs related changes for this function was with clang 20 ,
See https://gitlab.freedesktop.org/mesa/mes … 6e80cab0a7
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
FWIW - I think this should compile, but I don't know mesa or llvm:
auto DiagsClient = new clang::TextDiagnosticPrinter(
diag_log_stream,
diag_opts);
c->createVirtualFileSystem(*llvm::vfs::getRealFileSystem(),
DiagsClient);
c->createDiagnostics(DiagsClient);
BUT - since I have no idea what this code is doing, I'm worried about the c->createVirtualFileSystem() call being made several times, in a loop, perhaps? Because the old code would then simply reference the same llvm::vfs::getRealFileSystem(), but the new code would call createVirtualFileSystem() multiple times.
If the above isn't an issue, then the patched code looks something like this:
#if LLVM_VERSION_MAJOR >= 22
auto DiagsClient = new clang::TextDiagnosticPrinter(
diag_log_stream,
diag_opts);
c->createVirtualFileSystem(*llvm::vfs::getRealFileSystem(),
DiagsClient);
c->createDiagnostics(DiagsClient);
#else
c->createDiagnostics(
#if LLVM_VERSION_MAJOR >= 20
*llvm::vfs::getRealFileSystem(),
#endif
new clang::TextDiagnosticPrinter(
diag_log_stream,
diag_opts));
#endif
Offline
I almost posted something pretty similar but then I thought it was a bit strange that @Lone_Wolf couldn't come up with it himself because it looked fairly easy.
In the end it seems more like he's complaining about the random changes in API than asking for help
Offline
I posted the link to the older bugreport to give background info .
Could I write something myself ?
If it had to be in ecmascript 4, basic, pascal , java, : possibly
I know enough about general programming & OOP to read code many prog. languages and understand its structure, but that's it.
writing code and getting it to compile is much harder for me.
@twelveeighty :
I would probably create the vfs before using it.
I'm guessing c->createDiagnostics( indicates the declaration start of a function/procedure ?
If so, I'd expect a local var to be discarded after use and not affect other parts of the code / resources.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I re-read the commit message for 30633f3 again, this time more carefully. The key part is this (emphasis mine):
Both `CompilerInstance::create{FileManager,Diagnostics}()` now just use the VFS already in `CompilerInstance`
Originally I thought that the c->createVirtualFileSystem() call would attach a reference of the VFS into DiagsClient, but that's wrong. What instead happens is that since that commit, createVirtualFileSystem() modifies the "CompilerInstance", which is "c" and stores the created VFS there. You mention you're familiar with Java, so the equivalent to Java would be c.createVirtualFileSystem() changing the "c" object by storing the created filesystem as a member variable inside "c".
Now, I do not know if the clang code is robust enough that if you call createVirtualFileSystem() a 2nd time that it cleans up the existing "virtual file system" it had stored before, or if you've created a resource leak. Or, if clang expects you to manage it as a kind of "singleton" and only call it the first time and skip the 2nd time and now you will have to manage that resource somewhere, including its cleanup?
Edit: I should have asked before: what can you tell us about the lifetime of "c" a.k.a. the CompilerInstance, after that patched code, because if "c" gets destroyed/cleaned up right after this and every call to the patched code is with a "fresh" CompilerInstance, then we don't have to worry about it.
Last edited by twelveeighty (2025-09-30 22:47:54)
Offline
It seems the solution is simpler than I/we thought , see https://gitlab.freedesktop.org/mesa/mes … 868e9fd836
Thanks for the input, marking as solved.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline