Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[CMake] respect LLVMConfig.cmake's LLVM_DEFINITIONS #138587

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

jeremyd2019
Copy link
Contributor

@jeremyd2019 jeremyd2019 commented May 5, 2025

In #138329, _GNU_SOURCE was added for Cygwin, but when building Clang standalone against an installed LLVM this definition was not picked up, resulting in undefined strnlen. Follow the documentation in https://llvm.org/docs/CMake.html#developing-llvm-passes-out-of-source and add the LLVM_DEFINITIONS in standalone projects' cmakes.

@llvmbot llvmbot added the clang Clang issues not falling into any other category label May 5, 2025
@llvmbot
Copy link
Member

llvmbot commented May 5, 2025

@llvm/pr-subscribers-lldb
@llvm/pr-subscribers-mlir

@llvm/pr-subscribers-clang

Author: None (jeremyd2019)

Changes

In #138329, _GNU_SOURCE was added for Cygwin, but when building Clang standalone against an installed LLVM this definition was not picked up, resulting in undefined strnlen. Follow the documentation in https://llvm.org/docs/CMake.html#developing-llvm-passes-out-of-source and add the LLVM_DEFINITIONS in Clang's CMakeLists.txt.

Get rid of the list(REMOVE CMAKE_REQUIRED_DEFINITIONS -D_GNU_SOURCE) later, as list(REMOVE) is documented to remove all occurences of the item, not just the one that was just added. Instead, make use of cmake_push_check_state() and cmake_pop_check_state(), which is already used in other cmake files.


Full diff: https://github.com/llvm/llvm-project/pull/138587.diff

1 Files Affected:

  • (modified) clang/CMakeLists.txt (+7-4)
diff --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index c3f30e2a8e9c0..ab2ac9bc6b9ad 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -68,6 +68,10 @@ if(CLANG_BUILT_STANDALONE)
   option(CLANG_ENABLE_BOOTSTRAP "Generate the clang bootstrap target" OFF)
   option(LLVM_ENABLE_LIBXML2 "Use libxml2 if available." ON)
 
+  separate_arguments(LLVM_DEFINITIONS_LIST NATIVE_COMMAND ${LLVM_DEFINITIONS})
+  add_definitions(${LLVM_DEFINITIONS_LIST})
+  list(APPEND CMAKE_REQUIRED_DEFINITIONS ${LLVM_DEFINITIONS_LIST})
+
   include(AddLLVM)
   include(TableGen)
   include(HandleLLVMOptions)
@@ -183,18 +187,17 @@ check_include_file(sys/resource.h CLANG_HAVE_RLIMITS)
 # This check requires _GNU_SOURCE on linux
 check_include_file(dlfcn.h CLANG_HAVE_DLFCN_H)
 if( CLANG_HAVE_DLFCN_H )
+  include(CMakePushCheckState)
   include(CheckLibraryExists)
   include(CheckSymbolExists)
   check_library_exists(dl dlopen "" HAVE_LIBDL)
+  cmake_push_check_state()
   if( HAVE_LIBDL )
     list(APPEND CMAKE_REQUIRED_LIBRARIES dl)
   endif()
   list(APPEND CMAKE_REQUIRED_DEFINITIONS -D_GNU_SOURCE)
   check_symbol_exists(dladdr dlfcn.h CLANG_HAVE_DLADDR)
-  list(REMOVE_ITEM CMAKE_REQUIRED_DEFINITIONS -D_GNU_SOURCE)
-  if( HAVE_LIBDL )
-    list(REMOVE_ITEM CMAKE_REQUIRED_LIBRARIES dl)
-  endif()
+  cmake_pop_check_state()
 endif()
 
 set(CLANG_RESOURCE_DIR "" CACHE STRING

@jeremyd2019
Copy link
Contributor Author

jeremyd2019 commented May 5, 2025

If this is right, it should probably be done to other standalone-capable projects' CMakeLists.txt also (LLD in particular, for my interests). Actually, it seems there's nothing in LLD that requires _GNU_SOURCE on Cygwin...

@mstorsjo
Copy link
Member

mstorsjo commented May 6, 2025

If this is right, it should probably be done to other standalone-capable projects' CMakeLists.txt also (LLD in particular, for my interests). Actually, it seems there's nothing in LLD that requires _GNU_SOURCE on Cygwin...

Yep, indeed.

I guess the main question is who others regularly build in standalone mode and is familiar with how this is supposed to work, cmake-wise. CC @mgorny @tstellar who seem to have touched things for standalone build mode, and CC @petrhosek for overall cmake review.

@petrhosek
Copy link
Member

I'd slightly prefer doing this as two separate changes, that is the first change to replace the use of list(REMOVE ...) with CMakePushCheckState and the second change to use LLVMConfig.cmake's LLVM_DEFINITIONS since these are technically orthogonal.

I agree that the second change, that is using LLVMConfig.cmake's LLVM_DEFINITIONS, should be applied to other projects that support standalone builds like LLD.

@mstorsjo
Copy link
Member

mstorsjo commented May 6, 2025

I'd slightly prefer doing this as two separate changes, that is the first change to replace the use of list(REMOVE ...) with CMakePushCheckState and the second change to use LLVMConfig.cmake's LLVM_DEFINITIONS since these are technically orthogonal.

Sounds reasonable!

I agree that the second change, that is using LLVMConfig.cmake's LLVM_DEFINITIONS, should be applied to other projects that support standalone builds like LLD.

Ok, so this is an oversight, and it just happens that none of the projects that support standalone builds have been built in configurations where the defines in LLVM_DEFINITIONS have been essential so far?

@jeremyd2019
Copy link
Contributor Author

jeremyd2019 commented May 6, 2025

I agree that the second change, that is using LLVMConfig.cmake's LLVM_DEFINITIONS, should be applied to other projects that support standalone builds like LLD.

Is there a list somewhere or do I just rely on my grep-foo?

  • bolt
  • clang
  • flang
  • lld
  • lldb
  • mlir
  • polly

grep also turned up these, but they don't seem like things that link to LLVM, so probably shouldn't have these defines.

  • compiler-rt
  • libc
  • libclc
  • llvm-libgcc

The previous approach of using list(REMOVE ...) would remove *all*
occurences of the given item, not just the one appended above.
@jeremyd2019
Copy link
Contributor Author

Also, should all of those projects be updated in one pull request, or do I need to open a half-dozen more?

@mstorsjo
Copy link
Member

mstorsjo commented May 7, 2025

I agree that the second change, that is using LLVMConfig.cmake's LLVM_DEFINITIONS, should be applied to other projects that support standalone builds like LLD.

Is there a list somewhere or do I just rely on my grep-foo?

  • bolt
  • clang
  • flang
  • lld
  • lldb
  • mlir
  • polly

grep also turned up these, but they don't seem like things that link to LLVM, so probably shouldn't have these defines.

  • compiler-rt
  • libc
  • libclc
  • llvm-libgcc

Yes, this seems correct.

Also, should all of those projects be updated in one pull request, or do I need to open a half-dozen more?

I think it's fine to do that kind of project-wide consistency fixes all in one pull request, especially if the change in each of the projects isn't very large and involved.

@mgorny
Copy link
Member

mgorny commented May 7, 2025

Yeah, I think it's a good idea. Thanks for doing that!

In llvm#138329, _GNU_SOURCE was added for Cygwin, but when building Clang
standalone against an installed LLVM this definition was not picked up,
resulting in undefined strnlen.  Follow the documentation in
https://llvm.org/docs/CMake.html#developing-llvm-passes-out-of-source
and add the LLVM_DEFINITIONS in standalone projects' cmakes.
@jeremyd2019 jeremyd2019 force-pushed the clang-respect-llvm-definitons branch from a61d253 to b145528 Compare May 7, 2025 17:48
@jeremyd2019 jeremyd2019 changed the title [Clang][CMake] respect LLVMConfig.cmake's LLVM_DEFINITIONS [CMake] respect LLVMConfig.cmake's LLVM_DEFINITIONS May 7, 2025
@jeremyd2019
Copy link
Contributor Author

I rebased this on top of #138783 and adjusted the title and description. Now it should be in a good state to push cmake changes for other projects.

@llvmbot llvmbot added lld lldb mlir BOLT flang Flang issues not falling into any other category labels May 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BOLT clang Clang issues not falling into any other category flang Flang issues not falling into any other category lld lldb mlir
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants