-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[R-package] [gpu] Cmake version reported to be low when compiling the R package through build_r.R in Windows #6599
Comments
Thanks for using To work around it, change this line to 3.18 in your local copy of LightGBM (should work for you, as the only newer CMake features we've added do not affect the R build): Line 26 in 9a76aae
I hadn't considered this in #6550 (comment) ... R builds might end up finding the If you can answer those questions above, it'll help us debug this. |
@jameslamb I guess the confusion might occur due to different CMake (bundled or installed external). What we can do is,: Add a CMake version check in the build_r.R script to verify the path and version of CMake being used. This function will ensure that the correct version of CMake (3.28 or higher) is detected before the build process begins. If an outdated or bundled version is found, users will be prompted to update CMake or specify the correct path, preventing build failures related to CMake compatibility. I have not tried this out but maybe this could work? |
Thanks for the suggestion, but I don't want to add more complexity to Let's wait to hear the answers to the questions I asked before jumping to an implementation. |
Hi @jameslamb understandable, would keep a lookout on this issue. |
Thank you for your generous reply!
|
By using But |
Thanks for that! Can you please try installing the latest According to https://cran.r-project.org/bin/windows/Rtools/rtools43/news.html, the latest release of
That'd be new enough to compile the latest development version of LightGBM. |
Thank you for your reply. I have reinstalled the latest version of rtools43 and passed the check with cmake minimum version 3.28. Now when I rerun These two issues are troubling me. Do I not need to install Boost externally? The specified path is not working.
|
You do not need to install it externally. It's provided as a git submodule here. Could you try this? git submodule update --init --recursive
Rscript build_r.R --use-gpu If that succeeds, then we'll know that the issue you're facing has something to do with passing a custom Boost to the R build. And if that's true, we'll probably close this report and ask you to subscribe to #5960.
Thanks for that, but the contents of that file are a bit difficult for me to read (in a text editor on my Mac). Are the error messages you see the same ones reported at #6537? |
Thanks for your reply!
I tried this, and it didn' t work. And I have checked issue #6537. It seems we got the same error! |
Thanks for checking! Ok, if you don't mind could you please try 2 more ways, and see if either of them helps? Rscript build_r.R --use-gpu --use-msys2
Rscript build_r.R --use-gpu --use-mingw |
Wow, message:
test:
Thank you for your help! |
Oh great, glad to hear it! Rtools switched to the msys2 toolchain starting in R 4.0 (if I recall correctly), so it makes sense to me that that'd work better for you than MinGW. Sorry I didn't think of it before! In theory, LightGBM's R package is supposed to automatically fall back to that when compilation with Visual Studio fails Lines 133 to 141 in 5e4ab24
LightGBM/R-package/src/install.libs.R Lines 162 to 169 in 5e4ab24
But looking at it again... it'd be more accurate to say that LightGBM will fall back to MSYS2 if CMake cannot find Visual Studio and generate a build system based on it LightGBM/R-package/src/install.libs.R Lines 192 to 194 in 5e4ab24
In your case, Visual Studio 17 2022 was found. I see this in the logs you provided:
But then later on, compilation failed and also seems to be using MinGW headers (not the MSVC ones)
I don't understand why any Rtools headers would have been used if CMake correctly found MSVC 🤔 @StrikerRUS do you have any ideas? You're a lot better with Windows than I am. The logs I'm referring to are the file attached here: #6599 (comment) |
Sorry, I'm out of ideas right now. |
@jameslamb do we prefer using the MSVC headers over MinGW? |
No problem, thanks for looking!
If a new-enough MSVC exists on the system, then
Glad to hear this. If you'd be willing to help us a bit more @Vinnish-A , could you share a few more things?
It's a little difficult for me to get an interactive Windows development environment (I just have an old Windows laptop from 2017 that's very slow), so if it's easy for you to provide these details it'd help a lot. |
Of course, I will do my best to cooperate with your work.
|
Thanks so much for the quick response!
It is generally only used on Unix-like operating systems, but I thought maybe it'd matter for MinGW. Anyway, if you don't have it set that's good... one less thing to worry about 😁
Thanks! These logs look pretty similar to successful compilation with MSVC 2022 and R 4.3 in LightGBM's CI: https://github.com/microsoft/LightGBM/actions/runs/10415299953/job/28845578407#step:10:114 Some things to try based on what I see in
And please try completely deleting the |
I did as you said, but the environment variable In addition, I deleted
|
Thank you SO MUCH for all of the help, I really really appreciate it!
Excellent! That narrows it down even further... now we know this is only happening with the GPU variant of the package. That's very useful.
I think these are the relevant lines:
I think we can narrow this down to where the issue is happening, but I'm still confused about how it could happen. Here's the relevant block of code: LightGBM/include/LightGBM/utils/common.h Line 41 in d67ecf9
Re-written, with comments: // if the compiler is MSVC, just us <malloc.h> and assume it already has _mm_malloc() and _mm_free() and include the header
#if defined(_MSC_VER)
#include <malloc.h>
// otherwise, if the compile test run by cmake / autotools detected mm_malloc.h and the expected functions, include the header
#elif MM_MALLOC
#include <mm_malloc.h>
// otherwise, if using a GNU compiler (e.g. gcc) and it says it has memalign(), use that
#elif defined(__GNUC__) && defined(HAVE_MALLOC_H)
#include <malloc.h>
#define _mm_malloc(a, b) memalign(b, a)
#define _mm_free(a) free(a)
// otherwise, fall back to unaligned malloc()
#else
#include <stdlib.h>
#define _mm_malloc(a, b) malloc(a)
#define _mm_free(a) free(a)
#endif So this seems like just a more specific way to say the same thing I said above... the chosen compiler is MSVC but for some reason it's including the MinGW for standard library stuff instead. I will investigate this when I can. I'll try to replicate this on my Windows laptop and maybe do a build with If anyone else has ideas please do post them. I'd really like to figure out why this is happening and fix it if possible. |
Hi @jameslamb , thanks for clearing the MSVC vs MinGW case, I understand forcing something is largely undesireable, but multiple compiler components can lead to a break right. |
I don't understand what you're suggesting, sorry. If you have a Windows developmeny environment, it'd be helpful if you could try to reproduce this error and then try out your ideas to see if they fix it. |
Since you mentioned that even if the MSVC is selected, it is taking some MinGW stuff, so I suggested enforcing a compiler check and ensuring that components from there only are loaded. I do have a Windows development environment, I can look into it, how should i approach it?
|
Sure but what is "a compiler check"? Is that R code, CMake, preprocessor definitions in header files, etc.? This is what I don't understand about your proposal.
Install similar R, Rtools, and Visual Studio versions as what have been reported above. Clone the latest version of LightGBM. Run the build command Rscript build_r.R --use-gpu Try making changes to the code and repeat building until you've fixed the error or learn some new information that you think might help us narrow down the root cause further. |
this was a suggestion, I have not followed up with the implementation yet. |
At this point, I encourage you to clone the repo and look around in the code yourself. Start with |
@jameslamb works, will keep you in loop, thanks! |
On my Windows PC, my cmake version is 3.30
However, when running
Rscript build_r.R --use-gpu --opencl-library="C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.8/lib/x64/OpenCL.lib" --boost-librarydir=G:/boost_1_85_0/lib64-msvc-14.3
command, it prompts that my cmake version is too low.The text was updated successfully, but these errors were encountered: