windows: fix Envoy build on Windows #42687

anuraaga · 2025-12-18T07:53:59Z

Commit Message: Fix source to allow building on Windows
Additional Description:

I am interested in using Envoy on Windows with dynamic modules - I have already published pyvoy 0.2.0 using a patchset against 1.36.4 which is working great. This PR now updates the latest main to allow building on Windows, which required quite some more digging to accomodate changes to hermetic toolchains since then. FWIU, while Windows CI won't be restored, patches like this are still accepted.

For reference, the magic incantation to invoke Bazel

https://github.com/curioswitch/py-envoy-server/pull/17/files#diff-2855bcd1d44f7c4a97fdb2d631b71cf271ac70f3918e8f6242e54cf038952e64R59

If this is merged, I plan on having that build run nightly to try to catch Windows issues post-merge. Of course, if Envoy team could accept a small CI for Windows, just building the binary but no tests, that would be nice :) But I don't expect it.

There are two changes to non-Windows codepaths

For reverse tunnel downstream socket, a unix pipe is replaced with a pair of unix domain sockets (or TCP on windows). This allows using the Envoy OS helpers for this pattern. AFAIK, the only real difference with domain sockets would be they can be used bidirectionally, but if not, then at the kernel level they otherwise behave the same. Arguably using the helpers may be helping readability a little.

Otherwise, it is fixing some obvious syntax errors, including a dlopen wrapper around dynamic modules loading for Windows, replacing a convenience wrapper only available on newer windows with the older form, and other misc build tweaks.

/cc @mathetake @wbpcode

Risk Level:
Testing: CI
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

repokitteh-read-only · 2025-12-18T07:54:10Z

CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).
envoyproxy/dependency-shepherds assignee is @RyanTheOptimist

🐱

Caused by: #42687 was opened by anuraaga.

see: more, trace.

anuraaga · 2025-12-18T07:56:37Z

source/common/api/win32/os_sys_calls_impl.cc

 SysCallIntResult OsSysCallsImpl::setsockopt(os_fd_t sockfd, int level, int optname,
                                            const void* optval, socklen_t optlen) {
  if (optname == IP_RECVTOS || optname == IPV6_RECVTCLASS) {
-    const int rc = ::WSASetRecvIPEcn(sockfd, *(int*)optval == 1);


Only available on newer Windows

anuraaga · 2025-12-18T07:56:50Z

bazel/foreign_cc/luajit.patch

+new file mode 100755
+index 00000000..8fb0fbe8
+--- /dev/null
+++ b/luajit_build_win.sh


Shell version of old build.py that was deleted in refactoring

anuraaga · 2025-12-18T07:57:03Z

bazel/foreign_cc/cel-cpp.patch

+-    args.use_param_file(param_file_arg = "%s", use_always = True)
+-    args.add_all(transitive_descriptor_sets)
+
+    # Generate script to concatenate files listed in a parameter file into an output file.


Relatively large change

can you upstream this its hard enough maintaining lots of patches, and even harder if its for untested OS

any windows specific patches should be in a separate clearly named patch - so maintainers can quickly disable it if it doesnt apply, and it doesnt affect any other builds

anuraaga · 2025-12-18T07:57:38Z

bazel/repo.bzl

+            tag = config_data["build-image"]["tag"],
+        ))
+    else:
+        # yq via bazel doesn't work on Windows, but we don't need the file either


It downloads something but doesn't symlink or copy it in a way that it can be run, probably a bazel rule bug in @yq but it doesn't matter here

source/extensions/bootstrap/reverse_tunnel/upstream_socket_interface/reverse_tunnel_acceptor.h

anuraaga · 2025-12-18T07:58:22Z

source/server/BUILD

        "//envoy/filesystem:filesystem_interface",
        "//source/common/common:logger_lib",
        "//source/common/filesystem:filesystem_lib",
+        "//source/common/singleton:threadsafe_singleton",


Something about clang-cl seems to detect more of these missing dependencies (correctly)

Signed-off-by: Anuraag Agrawal <[email protected]>

phlax

Windows CI won't be restored,

that is correct, and the related point is that developers have no obligation to make things work or keep things working

patches like this are still accepted.

we can accept patches to make it work if they are low maintenance and non-intrusive - but patches for upstream really must be upstreamed

@anuraaga im wondering what the motivation for this is - ie are you imagining envoy being deployed on windows somewhere?

if that is the case, and putting aside my own thoughts on whether that is a good idea, my strong suggestion would be to iniitiate a downstream project that kept up to date and did any ci/testing that is required to maintain this

phlax · 2025-12-18T10:45:48Z

bazel/foreign_cc/BUILD

    tags = ["skip_on_windows"],
 )

+configure_make(


these rules need platform constraints so other platforms dont try to build with //...

AFAICT, this is already accomplished by the select statements, especially in cc_library. This is similar to maxmind_linux_darwin below

phlax · 2025-12-18T10:47:53Z

bazel/foreign_cc/cel-cpp.patch

+-    args.use_param_file(param_file_arg = "%s", use_always = True)
+-    args.add_all(transitive_descriptor_sets)
+
+    # Generate script to concatenate files listed in a parameter file into an output file.


can you upstream this its hard enough maintaining lots of patches, and even harder if its for untested OS

any windows specific patches should be in a separate clearly named patch - so maintainers can quickly disable it if it doesnt apply, and it doesnt affect any other builds

phlax · 2025-12-18T10:50:08Z

bazel/foreign_cc/luajit.patch

+
+ ls
+ cd src
+./msvcbuild.bat static


in this cases its obviously harder to upstream the patch - but im wondering if this .bat stuff is really needed and if it is whether it can be incorporated to existing patch/script - eg by setting an env var and calling it here if set

I considered adding to the existing script but since it's not using make, most of the logic is actually replicating the install command. It seemed clearer to keep them separate

I was able to remove the .bat patch, instead making sure to copy vc140.pdb to the output prefix, which is required when using /Zi as msvcbuild.bat forces to use.

I still kept the separate build_win.sh since it seems worth keeping it independent from the unix one

phlax · 2025-12-18T10:52:02Z

bazel/com_google_protoconverter.patch

+ create_compiler_config_setting(
+     name = "config_msvc",
+-    value = "msvc-cl",
+    values = ["msvc-cl", "clang-cl"],


please upstream all of this

phlax · 2025-12-18T10:56:30Z

tools/BUILD

    "check_repositories.sh",
 ])

+py_binary(


move this into tools/windows if its not relevant to anyone else

anuraaga · 2025-12-18T12:03:45Z

my strong suggestion would be to iniitiate a downstream project that kept up to date

Not sure if I follow exactly but yes, this is the linked pyvoy. And yeah, I don't expect Envoy to bring back any CI and will need to do testing.

I am wondering what part of this change is acceptable to you - if it's only the cc/h files that would still be helpful and I will just keep the build code forked. As we know, most of these dependencies aren't well maintained so while I can try to upstream changes, generally it won't work.

grpc-ecosystem/proto-converter#6

phlax · 2025-12-18T12:14:24Z

Not sure if I follow exactly

i meant something like an envoy-on-windows project that ran a build and some tests - we have a similar situation with unsupported arches (eg ppcle) and builds (eg openssl) already

ideally we make as few changes as possible wrt maintaining win-specific changes - i think the changes to our cc/h are unaviodable, and similar with some of the bazel selects etc - but for unsupported setups its even more important to upstream upstream changes as it significantly complicates maintaining patches

@TAOXUY @dchakarwarti would you be able to review a PR to upstream these changes?

anuraaga · 2025-12-18T12:29:00Z

i meant something like an envoy-on-windows project that ran a build and some tests

Ah I see. That would be the workflow I plan on running in py-envoy-server which just packages Envoy for use in Python.

https://github.com/curioswitch/py-envoy-server/blob/main/.github/workflows/envoy-windows-upstream.yaml

It builds envoy and runs some tests. Not a full suite but it checks basic functionality. I don't have a big reason to separate out yet another project specifically for envoy-on-windows but in terms of the envoy repo I think it's effectively the same.

but for unsupported setups its even more important to upstream upstream changes as it significantly complicates maintaining patches

Yeah I agree that it can get hard to recreate them. TBH I was already prepping a PR for protoconverter before finding that stale PR. I'm always for upstreaming where I can.

Is there any model where upstream patches with windows code can be made knowing that updates to the patch may break? I'm definitely not expecting the code to be stable for Windows and would just need to be able to react, not proact. But if even that's too much can keep those patches out of this PR.

Signed-off-by: Anuraag Agrawal <[email protected]>

anuraaga

I was able to simplify the build patches, sent grpc-ecosystem/proto-converter#7 in case it may be merged.

cel-cpp seems to have coincidentally started looking into Windows issues recently

google/cel-cpp#1811
google/cel-cpp@f1a2e8e

The now one-line patch here seems to work for now and in the future it should be removable.

anuraaga · 2025-12-19T04:19:46Z

bazel/foreign_cc/BUILD

    tags = ["skip_on_windows"],
 )

+configure_make(


AFAICT, this is already accomplished by the select statements, especially in cc_library. This is similar to maxmind_linux_darwin below

Signed-off-by: Anuraag Agrawal <[email protected]>

anuraaga

@phlax I was able to simplify the upstream patches a lot with pointers to upstreaming. Hopefully this looks better now

anuraaga · 2025-12-19T06:01:13Z

bazel/foreign_cc/luajit.patch

+
+ ls
+ cd src
+./msvcbuild.bat static


I was able to remove the .bat patch, instead making sure to copy vc140.pdb to the output prefix, which is required when using /Zi as msvcbuild.bat forces to use.

I still kept the separate build_win.sh since it seems worth keeping it independent from the unix one

Signed-off-by: Anuraag Agrawal <[email protected]>

…indows-build

ravenblackx · 2025-12-26T19:51:09Z

Ping for @wbpcode - but it's vacation season so mostly this ping is to shush the tool that nags on-call about stalled PRs, we don't expect prompt reviews across vacations.

anuraaga requested review from agrawroh, botengyao, mathetake, mattklein123 and yanavlasov as code owners December 18, 2025 07:54

repokitteh-read-only bot added the deps Approval required for changes to Envoy's external dependencies label Dec 18, 2025

repokitteh-read-only bot assigned RyanTheOptimist Dec 18, 2025

anuraaga commented Dec 18, 2025

View reviewed changes

Fix Envoy build on Windows

080845b

Signed-off-by: Anuraag Agrawal <[email protected]>

anuraaga force-pushed the fix-windows-build branch 2 times, most recently from 60681f4 to 1d6c084 Compare December 18, 2025 08:13

Remove redundant move

6fcbc41

Signed-off-by: Anuraag Agrawal <[email protected]>

anuraaga force-pushed the fix-windows-build branch from 1d6c084 to 6fcbc41 Compare December 18, 2025 08:19

Lints

8b02976

Signed-off-by: Anuraag Agrawal <[email protected]>

anuraaga force-pushed the fix-windows-build branch from b317301 to 8b02976 Compare December 18, 2025 09:02

phlax self-assigned this Dec 18, 2025

phlax reviewed Dec 18, 2025

View reviewed changes

anuraaga added 3 commits December 19, 2025 13:10

Simplify cel-cpp patch

cd0e20d

Signed-off-by: Anuraag Agrawal <[email protected]>

Simplify protoconverter patch

d42ba51

Signed-off-by: Anuraag Agrawal <[email protected]>

Move script to windows folder

e0bfb72

Signed-off-by: Anuraag Agrawal <[email protected]>

anuraaga commented Dec 19, 2025

View reviewed changes

anuraaga added 4 commits December 19, 2025 14:13

Simplify luajit patch

4d1fee3

Signed-off-by: Anuraag Agrawal <[email protected]>

Formatting

2ce46e6

Signed-off-by: Anuraag Agrawal <[email protected]>

Preserve trailing whitespace

e05b8fd

Signed-off-by: Anuraag Agrawal <[email protected]>

luajit incremental link

f1dc4f8

Signed-off-by: Anuraag Agrawal <[email protected]>

anuraaga commented Dec 19, 2025

View reviewed changes

anuraaga added 2 commits December 19, 2025 15:14

Remove leftover rule

db16aa1

Signed-off-by: Anuraag Agrawal <[email protected]>

Merge branch 'main' of https://github.com/envoyproxy/envoy into fix-w…

7e8341b

…indows-build

wbpcode self-assigned this Dec 22, 2025

windows: fix Envoy build on Windows #42687

Are you sure you want to change the base?

windows: fix Envoy build on Windows #42687

Conversation

anuraaga commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

repokitteh-read-only bot commented Dec 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

phlax left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anuraaga commented Dec 18, 2025

Uh oh!

phlax commented Dec 18, 2025

Uh oh!

anuraaga commented Dec 18, 2025

Uh oh!

anuraaga left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anuraaga left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ravenblackx commented Dec 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

anuraaga commented Dec 18, 2025 •

edited

Loading