-
Notifications
You must be signed in to change notification settings - Fork 586
Allow building on Windows using clang-cl toolchain
#6
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
Conversation
41068fe to
73dc8fe
Compare
|
Very nice, cool to see this building on Windows, thanks for sending the pull request! |
No worries. I know the fun of wrangling google3. 😁 |
It's not possible to build `gemma.cpp` with the standard MSVC front-end as it doesn't support arrays more than `0x7ffffffff` bytes (see Compiler Error C2148), however this isn't a problem with the optional Visual Studio Clang/LLVM frontend. This can be specified using the `-T` flag when running CMake: ``` $ cmake -B build -T ClangCL $ cmake --build build --config Release ``` Windows doesn't provide `pread`/`pwrite` so this must be emulated using the `ReadFile`/`WriteFile` Win32 APIs. `_CRT_SECURE_NO_WARNINGS` is defined to prevent a large number of warnings about using "depricated" function names (e.g. `close` instead of `_close`). `NOMINMAX` is defined to prevent the `min`/`max` macros from `windows.h` from conflicting with expressions like `std::min`. Generally libraries should avoid including `windows.h` in their public headers or define `WIN32_LEAN_AND_MEAN` before including the `windows.h` header, but this unfortunately isn't always the case.
Using a `CMakePresets.json` file makes it much easier to manage several alternate build configurations, such as the "ClangCL" build for Windows. This also makes it easier for tools like VSCode to run CMake-based builds.
|
Rebased onto the |
|
Can I request an exe download for those of us who are not familiar with building on Windows? |
|
Thanks for rebasing to dev, that's great! We are now ready to (attempt to) merge. I've resolved conflicts in README. |
|
@jan-wassenberg @austinvhuang It looks like this Copybara sync (c03b5da) reverted all the changes from this PR. Yay automation. |
|
ouch sorry about that, will take a closer look a bit later this evening. |
No worries! |
Sorry about this! We're still working out the kinks. I've restoring the changes in 84444c9. |
Sounds great! Thank you. |
|
Hi @GrahamboJangles,
PR #38 adds the Windows build to the GitHub Actions job. The Please be aware that Windows Defender currently detects this as malware—almost certainly a false positive (this is a good part of the reason for building it on GitHub's infrastructure and not just providing a binary I compiled myself). I'll see if there's anything I can do about this. |
|
@dcoles - Thanks for the reply. I wasn't even aware GitHub Actions existed, thanks for that. I think you can submit false positive reports to Windows Defender, VirusTotal, etc. But I'm not sure if this has to be done on a per-file basis or not. I did manage to build via Ubuntu WSL, is there a way I can manually build for Windows? |
|
Hi @GrahamboJangles,
I submitted the file to Microsoft, though haven't got a response back yet. Good news is that the latest build is no longer being detected as a threat. If you're interested in building it yourself, you can find the instructions in the README on the devbranch. Hopefully no more complex than building on Ubuntu WSL. Let me know if you find any parts of the instructions unclear. |
|
Even the latest build is flagged for me. I'm trying to build it myself, but get the following error: |
@GrahamboJangles You should run the CMake configure step ( Note: You can't build this in WSL. It should be run in a regular Windows The resulting binary should be |
|
Dumb mechanical engineer here playing around with cool software stuff that's over my head, but I keep getting |
|
Hi @nfe213, We're currently waging a bit of a war with Google's code sync tool Capybarra, which keeps undoing the changes from this PR. This is likely the reason that your build is currently failing. The most recent working commit on the |
|
Thanks, @dcoles! I'll check that out. Best of luck soldier. |
|
I tried to run with .\build\Release\gemma.exe --tokenizer tokenizer.spm --compressed_weights 2.0-2b-it-sfp.sbs --model 2b-it Abort at topology.cc:1011: Assert c.size_kib == 0: |
|
Hi, thanks for reporting. This has been fixed in Highway. We have a PR coming to the dev branch that updates the Highway version to pick up this change. |
|
:) It might just be the --model argument, for a Gemma 2 model that should be gemma2-2b-it. |


It's not possible to build
gemma.cppwith the standard MSVC front-end as it doesn't support arrays more than0x7ffffffffbytes (see Compiler Error C2148), however this isn't a problem with the optional Visual Studio Clang/LLVM-based frontend.This can be specified using the
-Tflag when running CMake:With the included
CMakePresets.json(second commit) this can be simplified to just:Windows doesn't provide
pread/pwriteso this must be emulated using theReadFile/WriteFileWin32 APIs.NOMINMAXis defined to prevent themin/maxmacros fromwindows.hfrom conflicting with expressions likestd::min. Generally libraries should avoid includingwindows.hin their public headers or defineWIN32_LEAN_AND_MEANbefore including thewindows.hheader, but this unfortunately isn't always the case.Tested with Visual Studio 2022 Build Tools: