Sure, I can try to guess the future values of _MSC_VER, since they seem quite regular (1910, 1920, 1930, …)
Well, it’s already in ROOT master
I’ll fix this one too
@Axel Commit mentioned for ManagedStatic.h was taken from here https://reviews.llvm.org/D80433 . Without this change current build produces invalid llvm-tblgen.exe which can’t accept any options, if you put even --help option then it says unknown option. I found how to fix it by that commit mentioned in link.
Besides everything that I mentioned in my post above there were no other errors and I got final working cling.exe which I tested successfully with simple C++ program.
1 Like
@bellenot ManagedStatic.h fix is in the ROOT master, but not yet in repo cloned by git clone --depth=1 http://root.cern.ch/git/cling.git. And this clone command is mentioned on Cling website Build page https://rawgit.com/root-project/cling/master/www/build.html . BTW, is it the main official home page of Cling?
Weird, it should pick up the same source code. Or did I miss something @Axel ?
I only know this one:
Also, if someone needs my Windows build of Cling I can share binaries, but don’t know where to upload them besides temporary (1-week) file sharing service, e.g. WeTransfer.
@bellenot @Axel Here are my MSVC-2022 compiled binaries of Cling if needed https://we.tl/t-fYxDqdpOBm, they were installed by CMAKE to folder c:/bin/cling/. Archived with https://7-zip.org/ archiver. Download link is active for 1 week from now. Compilation took about 1.5 hour on 8 threads (4 cores) on my old/slow laptop.
@moytra thank you very much! But we don’t provide Windows binaries for Cling (we do it for ROOT), and if you want to distribute the binaries you might consider using CPack
And the issue with the mismatch in ManagedStatic.h has been understood and will be fixed soon (thanks @Axel!)
@moytra I don’t see the issue with the unresolved symbol. But note that I don’t use Ninja, that might be the reason.
@bellenot Yes, probably it is due to Ninja, and I think the error comes from this part of CMakeLists.txt:
set_property(TARGET cling-demo APPEND_STRING PROPERTY LINK_FLAGS
"/EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00D_K@Z
/EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00DM@Z
/EXPORT:cling_runtime_internal_throwIfInvalidPointer")
To remind, I get error
Creating library lib\cling-demo.lib and object lib\cling-demo.exp
cling-demo.exp : error LNK2001: unresolved external symbol "?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00D_K@Z/EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00DM@Z/EXPORT:cling_runtime_internal_throwIfInvalidPointer" (?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00D_K@Z/EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00DM@Z/EXPORT:cling_runtime_internal_throwIfInvalidPointer)
bin\cling-demo.exe : fatal error LNK1120: 1 unresolved externals
It looks like newline endings are missing between these 3 linker lines that were added in CMakeLists.txt.
If I look at screenshot of cling-demo.exp, here https://prnt.sc/1uw1umb I see that it contains these 3 lines-options joined together without even spaces.
Do you know if cling-demo.exp is generated by Ninja or CMAKE? Somebody of those two made a mistake.
I think to fix an error for Ninja we can replace those 3 lines of Cmake file with 3 separate set_property lines, like (if we want to fix Ninja):
set_property(TARGET cling-demo APPEND_STRING PROPERTY LINK_FLAGS
" /EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00D_K@Z ")
set_property(TARGET cling-demo APPEND_STRING PROPERTY LINK_FLAGS
" /EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00DM@Z ")
set_property(TARGET cling-demo APPEND_STRING PROPERTY LINK_FLAGS
" /EXPORT:cling_runtime_internal_throwIfInvalidPointer ")
Or maybe just to place spaces instead of newlines between 3 options is enough.
I just checked with Ninja and this fix of CMakeLists.txt will work correctly:
set_property(TARGET cling-demo APPEND_STRING PROPERTY LINK_FLAGS
" /EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00D_K@Z /EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00DM@Z /EXPORT:cling_runtime_internal_throwIfInvalidPointer ")
(notice that I put all 3 options as single line and also put spaces between options)
Also works for Ninja if you do set_property() 3 times, like below:
set_property(TARGET cling-demo APPEND_STRING PROPERTY LINK_FLAGS
" /EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00D_K@Z ")
set_property(TARGET cling-demo APPEND_STRING PROPERTY LINK_FLAGS
" /EXPORT:?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00DM@Z ")
set_property(TARGET cling-demo APPEND_STRING PROPERTY LINK_FLAGS
" /EXPORT:cling_runtime_internal_throwIfInvalidPointer ")
(important Note!!! see that I placed spaces at the beginning of lines i.e. " /EXPORT...", without spaces you get same error, end-of-line spaces are not necessary but also could be good to place)
@Axel @bellenot I just noticed a very strange thing, when I make install target through command:
cmake --build . --config Release --target tools/cling/install --parallel
then I get following lines printed
...................
-- Generating done
-- Build files have been written to: D:/dev/_3party/cling/obj
[2/3] Install the project...
-- Install configuration: "Debug"
-- Up-to-date: C:/bin/cling/include/cling
.............
(many lines follow before and after)
Main notice here that it says Install configuration: "Debug", although I built Release and also you can see --config Release in my command.
Maybe there is some bug in cmake target tools/cling/install.
Can you try the standard way of building, as described here. I’m not sure Ninja on Windows is supported (I might investigate further whenever I have some spare time…)
Oh, sorry, I mean (in your example):
cmake -G"Visual Studio 17 2022" -A x64-Thost=x64 -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=c:/bin/cling/ ../src
and then:
cmake --build . --config Release
@bellenot Although maybe Ninja is not supported, but at least it worked for me fully except for the very single error that I showed. And that fix above (for set_property()) for me looks logical, because maybe other build systems may miss interpret newlines same as Ninja did, so looks like a good fix either to do 3 times set_property() or to join 3 options with spaces instead of newlines.
Also standard way mentioned on that web page says to build through cmake --build . and this will use Makefile builder, which does single-thread build by default with this command.
To build LLVM without multi-threads should be a huge pain. Even on my old laptop with 8 threads (4 cores) I waited for 1.5-2 hours to build Cling.
Either you have to do cmake --build . --parallel (add parallel option, which is not supported on older Cmake) or do make -j8 (which on Windows is also not supported, because it uses MSVC’s nmake). Hence using Ninja is probably most easy way to parallelize on Windows.
Also I did almost default way from that webpage except for adding -G Ninja.
Using cmake --build . --config Release builds in parallel by default (I use 32 threads). You can also force using n parallel jobs with:
cmake --build . --config Release -- -maxcpucount:n
@bellenot I can’t try standard way through “Visual Studio” generator because it takes 2 hours for me to compile Cling. And this cling-demo unresolved error happens on very last minutes of build. So I can’t just try it out, I need my laptop now and can’t wait 2 hours.
Also for me looks good if you support Ninja. Because it needs just single fix of cling-demo Cmake options that I showed above and then it works. I checked that my suggested fix makes Ninja to fully work from beginning to end. Fix of replacing newlines with spaces or doing 3-times set_property().
Hence you’ll support Ninja unoficially after this fix. 
Which is great!
Please read carefully what I wrote here. As I said, it runs in parallel by default. But OK, as you prefer, I’ll try with Ninja once I find some spare time
@bellenot You may also do blindly these set_property() fixes suggested above if you don’t have spare time to recompile whole Cling with Ninja. I tested them to work. As you wish!
And also those fixes for me looks logical because not only Ninja but some other build systems may also miss-interpret newlines somehow. It is better to replace newlines with guaranteed-working spaces.
OK, fine, I’ll check how to do it properly. Thanks
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.