cmake: fix MATH_LIBRARY check on Windows MSVC#22564
Conversation
|
I had a similar error but it went away with a clean tree. |
You're right, if I delete the build folder it goes through, but doesn't the bug remain latent as soon as find_library(MATH_LIBRARY m) is called elsewhere in the configure step (downstream project, upstream submodule, or even a simple re-configure reloading the cache), since DEFINED still evaluates to TRUE with the value MATH_LIBRARY-NOTFOUND and breaks the link, whereas if (MATH_LIBRARY) correctly evaluates *-NOTFOUND as falsy per CMake's if() contract ? |
|
We don’t want to call |
|
@ServeurpersoCom Is this change still needed or did the clean tree resolve the problem that you had? |
|
Deleting the "build" folder resolves the issue. |
TimexPeachtree
left a comment
There was a problem hiding this comment.
Great this made it possible for me to build it. After update gave issues.
|
The workaround is to delete the build dir, but this fix actually corrects the underlying problem. |
I mean i followed this 'cmake clean' command and didn't delete the build folder. It worked only after applying your fix. |
Overview
cmake : fix MATH_LIBRARY check on Windows MSVC
find_library(MATH_LIBRARY m) returns MATH_LIBRARY-NOTFOUND on MSVC, but if (DEFINED MATH_LIBRARY) is still TRUE, leading to target_link_libraries(... PRIVATE MATH_LIBRARY-NOTFOUND) and a 'cannot open m.lib' link error. Use idiomatic if (MATH_LIBRARY) which evaluates *-NOTFOUND as false.
This restores the truthy check that was in place before #22355; DEFINED is too permissive when MATH_LIBRARY is set elsewhere as *-NOTFOUND by an unrelated find_library() call earlier in configure.
Discovered while rebasing two GGML downstream projects
Refs #9908 (original old issue with the same Windows MSVC symptom)
Additional information
Requirements