-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Windows: protoc.exe built with MSVC cannot handle long path #2634
Comments
How do I repro this? |
Add It can be fixed by applying the following change. Then build a bazel with this change, use that bazel to run
|
I have a fix for this bug. The problem is that the proto compiler uses POSIX open(2) to open files which on Windows is declared in |
Nice, that's good to know! |
Create dedicated files for the long-path-aware Windows implementations of open/access/mkdir. This commit updates many BUT NOT ALL usages of <io.h> functions in protobuf's code base. Reason being is that there are no Bazel build rules for the unittest files that include <io.h>, so I decided to leave those alone. Thanks to this commit I can now build Bazel with MSVC without needing a short --output_user_base. Fixes #2634 See #2107 See protocolbuffers/protobuf#2891 Change-Id: I374726452300854a36e4628bb22cb7bbb12f3bad
Add implementations of open(2), mkdir(2), stat(2), etc. that support long paths under Windows (paths longer than MAX_PATH in <windows.h>, which is 260 characters). The implementations are in a separate namespace (google::protobuf::internal::win32), so they won't collide with the standard implementations in <io.h>, but after importing them with `using` they can be drop-in replacements. Fixes bazelbuild/bazel#2634 Fixes protocolbuffers#2891
Related: #2627
Got following error when enable MSVC as the default toolchain on Windows.
I believe the reason is because proto compiler built with MSVC cannot handle long path. The workaround could be using MSYS to build proto.exe, we can still get a msys free bazel in this way, but cannot build bazel without MSYS unless we solve this.
Is it an issue of protobuf instead of Bazel? //cc @dslomov @laszlocsomor
The text was updated successfully, but these errors were encountered: