Skip to content

fix: support for Windows (build script failures, runtime failures, updates) #206

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

Closed
wants to merge 0 commits into from

Conversation

avdaredevil
Copy link
Contributor

Windows Fixes

Note to author, you CANNOT do a mingw32 build without then linking the cygwin dlls, like: https://unix.stackexchange.com/questions/633316/how-to-statically-link-missing-libgcc-s-seh-1-dll-and-libstdc-6-dll-dlls-for-9/633321#633321

Summary

Couldn't use your library as-is on windows. The old clang-format library works for me, but it misses the binaries for linux-arm64 which is what our build servers use. Our code needs to work in both environments, hence this change!

How did you test this change?

  • I actually get output now!
    • image
  • Postinstall doesn't fail! (see changes!)

Resolved Issues

Copy link

vercel bot commented Jan 31, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
npm-clang-format-node-website ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 1, 2025 9:40am

@avdaredevil
Copy link
Contributor Author

@lumirlumir Could we please have this merged asap? Let me know if you need anything else

Also, thank you for making this!

Copy link

codecov bot commented Jan 31, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (c9f8cfe) to head (2e88796).

@@            Coverage Diff            @@
##              main      #206   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           11        11           
  Lines          439       439           
=========================================
  Hits           439       439           

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c9f8cfe...2e88796. Read the comment docs.

@lumirlumir
Copy link
Owner

Hello, @avdaredevil

Thank you for submitting the PR!

I’ll review this bug within the next 24 hours, so I kindly ask for your patience until then :)

@lumirlumir lumirlumir self-assigned this Jan 31, 2025
@lumirlumir lumirlumir added bug Something isn't working current: reviewing Currently reviewing it. labels Jan 31, 2025
@lumirlumir lumirlumir changed the title Fixed support for windows (build script failures, runtime failures, updates) fix: support for windows (build script failures, runtime failures, updates) Jan 31, 2025
@lumirlumir lumirlumir changed the title fix: support for windows (build script failures, runtime failures, updates) fix: support for Windows (build script failures, runtime failures, updates) Jan 31, 2025
Copy link

Labels have been automatically applied based on the conventional commit types.🏷️

Copy link

Labels have been automatically applied based on the conventional commit types.🏷️

@lumirlumir
Copy link
Owner

lumirlumir commented Jan 31, 2025

@avdaredevil

I understand why shx is needed, and that’s acceptable. However, I need to reproduce this bug to make a definitive decision!

I tried to reproduce this bug, but the postinstall and other script runs fine in Git Bash, PowerShell, and CMD. (Additionally, we previously fixed a similar postinstall bug on Windows in #171.) Could you provide detailed steps to reproduce this issue? I’m unable to reproduce it on my end.


+++

I cannot accept new binaries for the following two reasons:

  1. We are currently using version 19.1.7, which is the latest. :) (18.1.8 would actually be a downgrade at this point.) You can verify this by running npx clang-format --version (if you're using npm).
  2. For security reasons, I cannot accept external binaries provided by other users. Please refer to llvm-build-bump-pr.yml. The binaries we use are automatically built using GitHub Actions and QEMU+Docker Images.

Additionally, since we use Clang, CMake, and Ninja for building binaries, MinGW32, which is typically used for GNU GCC, is not required in our case.


+++

So, what if you update only the postinstall and other script without modifying the Windows native clang-format binaries? Would the same issue still occur?

I believe this issue may not be related to the binaries themselves, but rather to the postinstall and other script.

@lumirlumir lumirlumir marked this pull request as draft January 31, 2025 09:55
@avdaredevil
Copy link
Contributor Author

avdaredevil commented Jan 31, 2025

Hey @lumirlumir thanks for getting back to me!

  1. So, here's what I think is happening. Your environment already has the build tools added to your path, so you don't face a missing DLL issue (manifested as EXIT CODE: -1073741515 on pwsh, or 3221225781 within node.js)
    image
    a. Here's the binary dependencies of my exe file uploaded from LLVMs releases: image
    b. Here's the binary dependencies of your exe file image
    • This is all the ones that exist in my path for your EXE: image

My Conclusion: Your binary fails because it's missing those 3 critical DLL files. So you can either statically link them within the EXE when you build it, or make sure to package them with your release file


Now regarding shx I again believe because you may have linux tooling in your path, either via cygwin or wsl, you may be using those binaries rather than the native options.

  • I for example DO NOT have chmod or test in my path, because those are not windows tools. (I am not running wsl either).
  • The C:\Windows\System32 version of find DOES NOT support -type f or -exec syntax.
  • Additionally chmoding is not really a thing on windows (a file ending in .exe is enough) so that postinstall step is not required on Windows

Completely agree with the downgrade point, but I don't know how to test github actions, so if you could change my PR to, either:

  • Include those DLLs (statically, or dynamically)
  • OR, build with windows native tooling

then we could move forward, and you can remove my exe file :)

@avdaredevil avdaredevil marked this pull request as ready for review January 31, 2025 20:58
lumirlumir added a commit that referenced this pull request Feb 1, 2025
…tic linking flags on Windows

This PR is the follow up PR of #206

Added static link for `libgcc_s_seh-1.dll`, `libwinpthread-1.dll`, and `libstdc++-6.dll`.

This updates only affect Windows binary.
lumirlumir added a commit that referenced this pull request Feb 1, 2025
… static linking flags on Windows (#208)

This PR is the follow up PR of #206

Added static link for `libgcc_s_seh-1.dll`, `libwinpthread-1.dll`, and
`libstdc++-6.dll`.

This updates only affect Windows binary.

---

This pull request includes a change to the
`.github/workflows/llvm-build-bump-pr.yml` file to enhance the build
process for `clang-format`. The most important change is the addition of
static linking flags to the CMake build command.

Build process enhancement:

*
[`.github/workflows/llvm-build-bump-pr.yml`](diffhunk://#diff-d608eb75b383338d789a8908995e47499214a7cc55a847771ad73800464b18b0L372-R372):
Modified the CMake build command to include
`-DCMAKE_EXE_LINKER_FLAGS="-static -static-libgcc -static-libstdc++"`
for static linking.
@lumirlumir
Copy link
Owner

lumirlumir commented Feb 1, 2025

Thanks, @avdaredevil.

Your explanation helped me a lot. Now I can say that this PR manifests two problems:

  1. Failing scripts on Windows when using POSIX-only commands.
  2. Dynamic linking failure when clang-format.exe tries to find .dll files. This can be an issue if there are no .dll files in the user’s environment.

Here's how I will fix this problem:

  1. I looked into shx further and found that it is well-maintained and quite useful. So, I will accept this PR after first resolving the .dll issue.
  2. I will modify the clang-format.exe build process to use static linking for libgcc_s_seh-1.dll, libwinpthread-1.dll, and libstdc++-6.dll. (This change will apply only to Windows, as there were no issues in POSIX.) Please see fix(ci): update llvm-build-bump-pr.yml LLVM build script to include static linking flags on Windows #208, where I have added the static linking process.

Completely agree with the downgrade point, but I don't know how to test GitHub Actions.
So if you could modify my PR to either:

  • Include those DLLs (statically or dynamically), or
  • Build with Windows-native tooling,
    Then we could move forward, and you can remove my .exe file. :)

Since you have enabled the "Allow edits from maintainers" option, I can fix these issues myself. However, before proceeding, I wanted to check if you plan to fix this PR yourself.

The placement of the shx dependency is somewhat incorrect since it is maintained as part of a monorepo. I will leave a comment about this in case you want to address it yourself :)


If you have access to the GitHub Actions for this repository(maybe it's possible since it's public), here is the new Windows binary. Please take a look and test it first. If the issue still persists, let me know so I can fix it again.

https://github.com/lumirlumir/npm-clang-format-node/actions/runs/13087036390

image

The above one is the newly built Windows binary.

@lumirlumir lumirlumir added current: waiting for a reply Currently waiting for a reply. and removed current: reviewing Currently reviewing it. labels Feb 1, 2025
lumirlumir added a commit that referenced this pull request Feb 3, 2025
…up of #206) (#209)

This PR is the follow up PR of #206. Built new LLVM binaries.

---

This PR bumps the LLVM version from `llvmorg-19.1.7` to `llvmorg-19.1.7`
using LLVM binary that was built automatically. 🎉

See
[Actions](https://github.com/lumirlumir/npm-clang-format-node/actions/runs/13087036390)
for more details.
@avdaredevil
Copy link
Contributor Author

Hey @lumirlumir, hope you had a great weekend! My goal was to help with making sure this issue is fixed with the library, so if you're cool with it, I am okay with you fixing this PR with:

  • Removing my .exe file
  • Updating shx as a dependency on each package
  • Anything else that I forgot

Just a final note, I'd appreciate this PR being merged in, so if you could make the changes directly here that would be excellent!
Thanks again, and I appreciate you maintaining this for the OSS community! Kudos 🎉🎉

@lumirlumir
Copy link
Owner

lumirlumir commented Feb 4, 2025

@avdaredevil

image

I'm sorry, I tried to use and merge this PR, but I encountered a "permission denied" error as shown in the screenshot above. So, unfortunately, I had to create another branch and use your commit there.

Your contribution will be credited with the Co-authored-by tag and reflected as a contributor to this project.

Thank you for your kind words, and have a great week ahead :)


v1.3.1 has been released, and your commit has been merged in #215.

lumirlumir added a commit that referenced this pull request Feb 4, 2025
…dates) (original: #206) (#215)

See #206 for
details.

---------

Co-authored-by: Apoorv Verma [AP] <avdaredevil@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working current: waiting for a reply Currently waiting for a reply. 🏷️ type: fix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy