[LLVM][Clang][Cygwin] Fix building Clang for Cygwin #134494

mati865 · 2025-04-05T12:55:22Z

Changes summary:

[LLVM][Cygwin] Fix Signals compatibility with Cygwin API

Cygwin types sometimes do not match Linux exactly. Like in this case:

In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23,
                 from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34,
                 from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’:
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10:   required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’
/h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19:   required from here
/h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’
  106 |       : format_object_base(fmt), Vals(vals...) {
      |                                  ^~~~~~~~~~~~~

Casting here is safe and solves the issue.

[Clang][Cygwin] Fix symbol visibility definition

Currently building for Cygwin hits this error:

In file included from /h/projects/llvm-project/clang/lib/Basic/Attributes.cpp:17:
/h/projects/llvm-project/clang/include/clang/Basic/ParsedAttrInfo.h:180:73: error: invalid declarator before ‘;’ token
  180 | extern template class CLANG_TEMPLATE_ABI Registry<clang::ParsedAttrInfo>;

That's because CLANG_TEMPLATE_ABI ends up not being defined. The solution here is to follow MinGW case.

[Clang][Cygwin] Disable shared libs on Cygwin by default

This change follows MinGW decisions, otherwise build with GCC fail with:

FAILED: bin/msys-clang-cpp-21.0git.dll lib/libclang-cpp.dll.a
...
/usr/lib/gcc/x86_64-pc-msys/13.3.0/../../../../x86_64-pc-msys/bin/ld: error: export ordinal too large: 92250

[Clang][Cygwin] Remove erroneous _WIN32 define and clean up Cygwin code

With this define present and building with Clang the build fails:

In file included from /h/projects/llvm-project/clang/tools/libclang/CIndexer.cpp:36:
In file included from /usr/include/w32api/windows.h:69:
In file included from /usr/include/w32api/windef.h:9:
In file included from /usr/include/w32api/minwindef.h:163:
In file included from /usr/include/w32api/winnt.h:1658:
In file included from /usr/lib/clang/20/include/x86intrin.h:15:
In file included from /usr/lib/clang/20/include/immintrin.h:24:
In file included from /usr/lib/clang/20/include/xmmintrin.h:31:
/usr/lib/clang/20/include/mm_malloc.h:45:22: error: use of undeclared identifier '_aligned_malloc'; did you mean 'aligned_alloc'?
   45 |   __mallocedMemory = _aligned_malloc(__size, __align);
      |                      ^

Removing it allows the build with Clang to succeed and doesn't break build with GCC.

With these changes, LLVM and Clang become buildable for Cygwin.

GCC config (using MSYS2 GCC):
CFLAGS="-D_GNU_SOURCE=1" CXXFLAGS="-D_GNU_SOURCE=1" CPPFLAGS="-D_GNU_SOURCE=1" cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-cygwin -DLLVM_HOST_TRIPLE=x86_64-pc-cygwin -DLLVM_TARGETS_TO_BUILD="AArch64;X86" -DLIBCLANG_BUILD_STATIC=ON ../llvm
-D_GNU_SOURCE=1 is important because GCC on Cygwin, opposed to GCC on Linux, does not define it.

Clang config (using msys2/MSYS2-packages#5308):
CC=clang CXX=clang++ cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-cygwin -DLLVM_HOST_TRIPLE=x86_64-pc-cygwin -DLLVM_TARGETS_TO_BUILD="AArch64;X86" -DLIBCLANG_BUILD_STATIC=ON ../llvm

Split out from #134458

github-actions · 2025-04-05T12:58:43Z

✅ With the latest revision this PR passed the C/C++ code formatter.

llvm/lib/Support/Unix/Signals.inc

clang/tools/libclang/CMakeLists.txt

llvmbot · 2025-04-09T18:50:56Z

@llvm/pr-subscribers-clang

Author: Mateusz Mikuła (mati865)

Changes

With these changes, LLVM and Clang become buildable for Cygwin.

GCC config (using MSYS2 GCC):
CFLAGS="-D_GNU_SOURCE=1" CXXFLAGS="-D_GNU_SOURCE=1" CPPFLAGS="-D_GNU_SOURCE=1" cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-cygwin -DLLVM_HOST_TRIPLE=x86_64-pc-cygwin -DLLVM_TARGETS_TO_BUILD="AArch64;X86" -DLIBCLANG_BUILD_STATIC=ON ../llvm
-D_GNU_SOURCE=1 is important because GCC on Cygwin, opposed to GCC on Linux, does not define it.

Clang config (using msys2/MSYS2-packages#5308):
CC=clang CXX=clang++ cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-cygwin -DLLVM_HOST_TRIPLE=x86_64-pc-cygwin -DLLVM_TARGETS_TO_BUILD="AArch64;X86" -DLIBCLANG_BUILD_STATIC=ON ../llvm

Split out from #134458

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

5 Files Affected:

(modified) clang/include/clang/Support/Compiler.h (+1-1)
(modified) clang/tools/CMakeLists.txt (+3-2)
(modified) clang/tools/libclang/CIndexer.cpp (-1)
(modified) clang/tools/libclang/CMakeLists.txt (+2-1)
(modified) llvm/lib/Support/Unix/Signals.inc (+1-1)

diff --git a/clang/include/clang/Support/Compiler.h b/clang/include/clang/Support/Compiler.h
index 5a74f8e3b6723..e1ae3eda4ccc2 100644
--- a/clang/include/clang/Support/Compiler.h
+++ b/clang/include/clang/Support/Compiler.h
@@ -50,7 +50,7 @@
 #define CLANG_EXPORT_TEMPLATE
 #endif
 #elif defined(__ELF__) || defined(__MINGW32__) || defined(_AIX) ||             \
-    defined(__MVS__)
+    defined(__MVS__) || defined(__CYGWIN__)
 #define CLANG_ABI LLVM_ATTRIBUTE_VISIBILITY_DEFAULT
 #define CLANG_TEMPLATE_ABI LLVM_ATTRIBUTE_VISIBILITY_DEFAULT
 #define CLANG_EXPORT_TEMPLATE
diff --git a/clang/tools/CMakeLists.txt b/clang/tools/CMakeLists.txt
index 9634eb12080c8..50e3d694236ac 100644
--- a/clang/tools/CMakeLists.txt
+++ b/clang/tools/CMakeLists.txt
@@ -26,9 +26,10 @@ endif()
 add_clang_subdirectory(c-index-test)
 
 add_clang_subdirectory(clang-refactor)
-# For MinGW we only enable shared library if LLVM_LINK_LLVM_DYLIB=ON.
+# For MinGW/Cygwin we only enable shared library if LLVM_LINK_LLVM_DYLIB=ON.
 # Without that option resulting library is too close to 2^16 DLL exports limit.
-if(UNIX OR (MSVC AND LLVM_BUILD_LLVM_DYLIB_VIS) OR (MINGW AND LLVM_LINK_LLVM_DYLIB))
+if((UNIX AND NOT CYGWIN) OR (MSVC AND LLVM_BUILD_LLVM_DYLIB_VIS) OR
+  ((MINGW OR CYGWIN) AND LLVM_LINK_LLVM_DYLIB))
   add_clang_subdirectory(clang-shlib)
 endif()
 
diff --git a/clang/tools/libclang/CIndexer.cpp b/clang/tools/libclang/CIndexer.cpp
index 12d9d418dea51..1b9d58bc439ad 100644
--- a/clang/tools/libclang/CIndexer.cpp
+++ b/clang/tools/libclang/CIndexer.cpp
@@ -29,7 +29,6 @@
 #ifdef __CYGWIN__
 #include <cygwin/version.h>
 #include <sys/cygwin.h>
-#define _WIN32 1
 #endif
 
 #ifdef _WIN32
diff --git a/clang/tools/libclang/CMakeLists.txt b/clang/tools/libclang/CMakeLists.txt
index 299c14660f3d4..37a939ffcada7 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -106,7 +106,8 @@ if (LLVM_EXPORTED_SYMBOL_FILE)
                      DEPENDS ${LIBCLANG_VERSION_SCRIPT_FILE})
 endif()
 
-if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
+if((NOT (WIN32 OR CYGWIN) AND LLVM_ENABLE_PIC) OR
+  ((WIN32 OR CYGWIN) AND NOT LIBCLANG_BUILD_STATIC))
   set(ENABLE_SHARED SHARED)
 endif()
 
diff --git a/llvm/lib/Support/Unix/Signals.inc b/llvm/lib/Support/Unix/Signals.inc
index 30e5f40193974..230763e729520 100644
--- a/llvm/lib/Support/Unix/Signals.inc
+++ b/llvm/lib/Support/Unix/Signals.inc
@@ -847,7 +847,7 @@ void llvm::sys::PrintStackTrace(raw_ostream &OS, int Depth) {
 
     const char *name = strrchr(dlinfo.dli_fname, '/');
     if (!name)
-      OS << format(" %-*s", width, dlinfo.dli_fname);
+      OS << format(" %-*s", width, (const char *)dlinfo.dli_fname);
     else
       OS << format(" %-*s", width, name + 1);

llvmbot · 2025-04-09T18:50:57Z

@llvm/pr-subscribers-llvm-support

Author: Mateusz Mikuła (mati865)

Changes

With these changes, LLVM and Clang become buildable for Cygwin.

GCC config (using MSYS2 GCC):
CFLAGS="-D_GNU_SOURCE=1" CXXFLAGS="-D_GNU_SOURCE=1" CPPFLAGS="-D_GNU_SOURCE=1" cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-cygwin -DLLVM_HOST_TRIPLE=x86_64-pc-cygwin -DLLVM_TARGETS_TO_BUILD="AArch64;X86" -DLIBCLANG_BUILD_STATIC=ON ../llvm
-D_GNU_SOURCE=1 is important because GCC on Cygwin, opposed to GCC on Linux, does not define it.

Clang config (using msys2/MSYS2-packages#5308):
CC=clang CXX=clang++ cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-cygwin -DLLVM_HOST_TRIPLE=x86_64-pc-cygwin -DLLVM_TARGETS_TO_BUILD="AArch64;X86" -DLIBCLANG_BUILD_STATIC=ON ../llvm

Split out from #134458

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

5 Files Affected:

(modified) clang/include/clang/Support/Compiler.h (+1-1)
(modified) clang/tools/CMakeLists.txt (+3-2)
(modified) clang/tools/libclang/CIndexer.cpp (-1)
(modified) clang/tools/libclang/CMakeLists.txt (+2-1)
(modified) llvm/lib/Support/Unix/Signals.inc (+1-1)

diff --git a/clang/include/clang/Support/Compiler.h b/clang/include/clang/Support/Compiler.h
index 5a74f8e3b6723..e1ae3eda4ccc2 100644
--- a/clang/include/clang/Support/Compiler.h
+++ b/clang/include/clang/Support/Compiler.h
@@ -50,7 +50,7 @@
 #define CLANG_EXPORT_TEMPLATE
 #endif
 #elif defined(__ELF__) || defined(__MINGW32__) || defined(_AIX) ||             \
-    defined(__MVS__)
+    defined(__MVS__) || defined(__CYGWIN__)
 #define CLANG_ABI LLVM_ATTRIBUTE_VISIBILITY_DEFAULT
 #define CLANG_TEMPLATE_ABI LLVM_ATTRIBUTE_VISIBILITY_DEFAULT
 #define CLANG_EXPORT_TEMPLATE
diff --git a/clang/tools/CMakeLists.txt b/clang/tools/CMakeLists.txt
index 9634eb12080c8..50e3d694236ac 100644
--- a/clang/tools/CMakeLists.txt
+++ b/clang/tools/CMakeLists.txt
@@ -26,9 +26,10 @@ endif()
 add_clang_subdirectory(c-index-test)
 
 add_clang_subdirectory(clang-refactor)
-# For MinGW we only enable shared library if LLVM_LINK_LLVM_DYLIB=ON.
+# For MinGW/Cygwin we only enable shared library if LLVM_LINK_LLVM_DYLIB=ON.
 # Without that option resulting library is too close to 2^16 DLL exports limit.
-if(UNIX OR (MSVC AND LLVM_BUILD_LLVM_DYLIB_VIS) OR (MINGW AND LLVM_LINK_LLVM_DYLIB))
+if((UNIX AND NOT CYGWIN) OR (MSVC AND LLVM_BUILD_LLVM_DYLIB_VIS) OR
+  ((MINGW OR CYGWIN) AND LLVM_LINK_LLVM_DYLIB))
   add_clang_subdirectory(clang-shlib)
 endif()
 
diff --git a/clang/tools/libclang/CIndexer.cpp b/clang/tools/libclang/CIndexer.cpp
index 12d9d418dea51..1b9d58bc439ad 100644
--- a/clang/tools/libclang/CIndexer.cpp
+++ b/clang/tools/libclang/CIndexer.cpp
@@ -29,7 +29,6 @@
 #ifdef __CYGWIN__
 #include <cygwin/version.h>
 #include <sys/cygwin.h>
-#define _WIN32 1
 #endif
 
 #ifdef _WIN32
diff --git a/clang/tools/libclang/CMakeLists.txt b/clang/tools/libclang/CMakeLists.txt
index 299c14660f3d4..37a939ffcada7 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -106,7 +106,8 @@ if (LLVM_EXPORTED_SYMBOL_FILE)
                      DEPENDS ${LIBCLANG_VERSION_SCRIPT_FILE})
 endif()
 
-if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
+if((NOT (WIN32 OR CYGWIN) AND LLVM_ENABLE_PIC) OR
+  ((WIN32 OR CYGWIN) AND NOT LIBCLANG_BUILD_STATIC))
   set(ENABLE_SHARED SHARED)
 endif()
 
diff --git a/llvm/lib/Support/Unix/Signals.inc b/llvm/lib/Support/Unix/Signals.inc
index 30e5f40193974..230763e729520 100644
--- a/llvm/lib/Support/Unix/Signals.inc
+++ b/llvm/lib/Support/Unix/Signals.inc
@@ -847,7 +847,7 @@ void llvm::sys::PrintStackTrace(raw_ostream &OS, int Depth) {
 
     const char *name = strrchr(dlinfo.dli_fname, '/');
     if (!name)
-      OS << format(" %-*s", width, dlinfo.dli_fname);
+      OS << format(" %-*s", width, (const char *)dlinfo.dli_fname);
     else
       OS << format(" %-*s", width, name + 1);

clang/tools/libclang/CIndexer.cpp

jeremyd2019 · 2025-04-23T21:05:28Z

@mstorsjo maybe you could look at this PR too? sorry to bug you so much, but it doesn't seem like anyone else is very interested in cygwin here 😉

mstorsjo · 2025-04-25T21:04:35Z

These changes mostly look good to me, but it all feels a bit unclear to me still. So I'd appreciate e.g. one or a few sentences in the commit message on each of these commits, to explain a bit about the why/how and how things work in other preexisting environments. Is this for building LLVM/Clang with GCC, or for building LLVM/Clang with Clang?

E.g. for "Fix Signals compatibility with Cygwin API", what error/warning do we get without this? What system data structure has a different definition on Cygwin compared with other common unixes, that causes this incompatibility?

(Also, for that change, maybe it'd be more idiomatic C++ code with static_cast<const char *>().)

For "Fix symbol visibility definition" - is this about using the recent mingw-originated feature of setting symbol visibility for excluding symbols from autoexport? I.e. this is for when building LLVM with Clang? The commit message "fix" is quite vague.

"Disable shared libs on Cygwin by default" mostly looks reasonable, it's something where it makes sense to do whatever we've set up to do for mingw. But even there it would be nice with one sentence saying what issue you were running into before doing this change.

"Remove erroneous define and clean it up" - a mention of what the problem is, maybe some digging of where this code originated, and a mention of why it's not relevant any longer would be good.

"Avoid unwanted shared libclang builds" - Also here, mention what happens right now (and under which circumstances).

Then secondly, LLVM only allows "squash and merge" merging of PRs - so all these nicely split changes (with individual explanations soon, I'd hope!) would end up all mushed together. So unfortunately, to preserve the info about each of them, they'd need to be filed in separate individual PRs. Luckily most of these changes don't build on top of each other (even if you might not be able to build things properly unless you have all of them applied at once?), so it should be fairly straightforward to file all those PRs in parallel.

Most of these should be easy to approve and merge if filed separately with a couple of sentences each explaining the fix.

jeremyd2019 · 2025-04-25T21:43:51Z

E.g. for "Fix Signals compatibility with Cygwin API", what error/warning do we get without this? What system data structure has a different definition on Cygwin compared with other common unixes, that causes this incompatibility?

(Also, for that change, maybe it'd be more idiomatic C++ code with static_cast<const char *>().)

I thought about suggesting that, but I didn't remember if static_cast would blow up if adding a const qualifier.

Cygwin defines DL_info::dli_fname as char dli_fname[PATH_MAX];. The template on format gets confused by getting a char[] instead of a char *, even though they should be the same thing to C.

"Remove erroneous define and clean it up" - a mention of what the problem is, maybe some digging of where this code originated, and a mention of why it's not relevant any longer would be good.

Because Cygwin has dladdr now, and it already does the legwork of converting the path to POSIX. It seems to me that code is really old, I don't know why the Windows path doesn't just use GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS like dladdr does (that's been available since XP IIRC), and it is had support for an old Cygwin path conversion function not supported since the switch to 64-bit.

mati865 · 2025-04-27T16:36:23Z

These changes mostly look good to me, but it all feels a bit unclear to me still. So I'd appreciate e.g. one or a few sentences in the commit message on each of these commits, to explain a bit about the why/how and how things work in other preexisting environments.

Sure, I'll do that within the next few days.

Is this for building LLVM/Clang with GCC, or for building LLVM/Clang with Clang?

Both, initially I started with GCC and then added fixes for building with Clang.

Then secondly, LLVM only allows "squash and merge" merging of PRs - so all these nicely split changes (with individual explanations soon, I'd hope!) would end up all mushed together. So unfortunately, to preserve the info about each of them, they'd need to be filed in separate individual PRs.

I think the descriptions would be preserved if I combined them all into PR description. I've split the commits only to make the review easier.

Luckily most of these changes don't build on top of each other (even if you might not be able to build things properly unless you have all of them applied at once?), so it should be fairly straightforward to file all those PRs in parallel.

Yeah, this won't build at all without all commits (or most of in case of GCC). So, it's not like there is anything to lose.

mstorsjo · 2025-04-27T21:09:37Z

Then secondly, LLVM only allows "squash and merge" merging of PRs - so all these nicely split changes (with individual explanations soon, I'd hope!) would end up all mushed together. So unfortunately, to preserve the info about each of them, they'd need to be filed in separate individual PRs.

I think the descriptions would be preserved if I combined them all into PR description. I've split the commits only to make the review easier.

Ok, fair enough - we can keep this as one single PR. If the PR description contains all the info needed to cover the why/how for all the changes here that's probably fine too.

Cygwin types sometimes do not match Linux exactly. Like in this case: ``` In file included from /h/projects/llvm-project/llvm/include/llvm/Support/Error.h:23, from /h/projects/llvm-project/llvm/include/llvm/Support/FileSystem.h:34, from /h/projects/llvm-project/llvm/lib/Support/Signals.cpp:22: /h/projects/llvm-project/llvm/include/llvm/Support/Format.h: In instantiation of ‘llvm::format_object<Ts>::format_object(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’: /h/projects/llvm-project/llvm/include/llvm/Support/Format.h:126:10: required from ‘llvm::format_object<Ts ...> llvm::format(const char*, const Ts& ...) [with Ts = {int, char [4096]}]’ /h/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:850:19: required from here /h/projects/llvm-project/llvm/include/llvm/Support/Format.h:106:34: error: no matching function for call to ‘std::tuple<int, char [4096]>::tuple(const int&, const char [4096])’ 106 | : format_object_base(fmt), Vals(vals...) { | ^~~~~~~~~~~~~ ``` Casting here is safe and solves the issue.

Currently building for Cygwin hits this error: ``` In file included from /h/projects/llvm-project/clang/lib/Basic/Attributes.cpp:17: /h/projects/llvm-project/clang/include/clang/Basic/ParsedAttrInfo.h:180:73: error: invalid declarator before ‘;’ token 180 | extern template class CLANG_TEMPLATE_ABI Registry<clang::ParsedAttrInfo>; ``` That's because `CLANG_TEMPLATE_ABI` ends up not being defined. The solution here is to follow MinGW case.

This change follows MinGW decisions, otherwise build with GCC fail with: ``` FAILED: bin/msys-clang-cpp-21.0git.dll lib/libclang-cpp.dll.a ... /usr/lib/gcc/x86_64-pc-msys/13.3.0/../../../../x86_64-pc-msys/bin/ld: error: export ordinal too large: 92250 ``` Co-authored-by: jeremyd2019 <[email protected]>

With this define present and building with Clang the build fails: ``` In file included from /h/projects/llvm-project/clang/tools/libclang/CIndexer.cpp:36: In file included from /usr/include/w32api/windows.h:69: In file included from /usr/include/w32api/windef.h:9: In file included from /usr/include/w32api/minwindef.h:163: In file included from /usr/include/w32api/winnt.h:1658: In file included from /usr/lib/clang/20/include/x86intrin.h:15: In file included from /usr/lib/clang/20/include/immintrin.h:24: In file included from /usr/lib/clang/20/include/xmmintrin.h:31: /usr/lib/clang/20/include/mm_malloc.h:45:22: error: use of undeclared identifier '_aligned_malloc'; did you mean 'aligned_alloc'? 45 | __mallocedMemory = _aligned_malloc(__size, __align); | ^ ``` Removing it allows the build with Clang to succeed and doesn't break build with GCC. Co-authored-by: Jeremy Drake <[email protected]>

mati865 · 2025-05-01T11:50:24Z

Okay, you were right.
Keeping this in a single description hurts readability a lot.

So I have opened a series of smaller PRs:
#138117
#138118
#138119
#138120

This branch is equal to the other ones (once they are merged together), so we can go either way.
I think you can publish them from drafts once you are happy with them. You can also mention me on GH, so I get the notification instantly and publish them.

mstorsjo · 2025-05-02T08:08:26Z

Okay, you were right. Keeping this in a single description hurts readability a lot.

So I have opened a series of smaller PRs: #138117 #138118 #138119 #138120

This branch is equal to the other ones (once they are merged together), so we can go either way. I think you can publish them from drafts once you are happy with them. You can also mention me on GH, so I get the notification instantly and publish them.

All these should be merged now, so this PR can probably be closed now.

mati865 · 2025-05-02T08:58:53Z

Thank you for taking care of it!

mati865 changed the title ~~Fix Singals compatibility with Cygwin API~~ [LLVM][Clang][Cygwin] Fix building Clang for Cygwin Apr 5, 2025

mati865 force-pushed the cygwin-build-fix branch from ef352ad to 164b90e Compare April 5, 2025 13:02

jeremyd2019 reviewed Apr 5, 2025

View reviewed changes

llvm/lib/Support/Unix/Signals.inc Outdated Show resolved Hide resolved

mati865 force-pushed the cygwin-build-fix branch 2 times, most recently from a4e7abd to a55831f Compare April 8, 2025 18:59

jeremyd2019 reviewed Apr 8, 2025

View reviewed changes

clang/tools/libclang/CMakeLists.txt Outdated Show resolved Hide resolved

mati865 force-pushed the cygwin-build-fix branch 2 times, most recently from ededfae to 07f6ee7 Compare April 8, 2025 19:39

mati865 marked this pull request as ready for review April 9, 2025 18:50

llvmbot added clang Clang issues not falling into any other category clang:as-a-library libclang and C++ API llvm:support labels Apr 9, 2025

jeremyd2019 reviewed Apr 9, 2025

View reviewed changes

clang/tools/libclang/CIndexer.cpp Outdated Show resolved Hide resolved

This was referenced Apr 14, 2025

[Clang] [Driver] add a Cygwin ToolChain #135691

Merged

enable --disable-dependency-tracking on CYGWIN also mstorsjo/llvm-mingw#490

Merged

mati865 force-pushed the cygwin-build-fix branch 3 times, most recently from b81759a to 60c7a44 Compare April 23, 2025 22:58

jeremyd2019 approved these changes Apr 23, 2025

View reviewed changes

mati865 and others added 3 commits May 1, 2025 11:57

mati865 marked this pull request as draft May 1, 2025 11:25

mati865 force-pushed the cygwin-build-fix branch from 60c7a44 to 062ad30 Compare May 1, 2025 11:26

mati865 closed this May 2, 2025

mati865 deleted the cygwin-build-fix branch May 2, 2025 08:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[LLVM][Clang][Cygwin] Fix building Clang for Cygwin #134494

[LLVM][Clang][Cygwin] Fix building Clang for Cygwin #134494

mati865 commented Apr 5, 2025 •

edited

Loading

github-actions bot commented Apr 5, 2025 •

edited

Loading

llvmbot commented Apr 9, 2025

llvmbot commented Apr 9, 2025

jeremyd2019 commented Apr 23, 2025

mstorsjo commented Apr 25, 2025

jeremyd2019 commented Apr 25, 2025 •

edited

Loading

mati865 commented Apr 27, 2025

mstorsjo commented Apr 27, 2025

mati865 commented May 1, 2025

mstorsjo commented May 2, 2025

mati865 commented May 2, 2025

[LLVM][Clang][Cygwin] Fix building Clang for Cygwin #134494

[LLVM][Clang][Cygwin] Fix building Clang for Cygwin #134494

Conversation

mati865 commented Apr 5, 2025 • edited Loading

[LLVM][Cygwin] Fix Signals compatibility with Cygwin API

[Clang][Cygwin] Fix symbol visibility definition

[Clang][Cygwin] Disable shared libs on Cygwin by default

[Clang][Cygwin] Remove erroneous _WIN32 define and clean up Cygwin code

github-actions bot commented Apr 5, 2025 • edited Loading

llvmbot commented Apr 9, 2025

llvmbot commented Apr 9, 2025

jeremyd2019 commented Apr 23, 2025

mstorsjo commented Apr 25, 2025

jeremyd2019 commented Apr 25, 2025 • edited Loading

mati865 commented Apr 27, 2025

mstorsjo commented Apr 27, 2025

mati865 commented May 1, 2025

mstorsjo commented May 2, 2025

mati865 commented May 2, 2025

mati865 commented Apr 5, 2025 •

edited

Loading

github-actions bot commented Apr 5, 2025 •

edited

Loading

jeremyd2019 commented Apr 25, 2025 •

edited

Loading