UnsatisfiedLinkError with --experimental_remote_cache_compression on Windows
#16041
Labels
P2
We'll consider working on this in future. (Assignee optional)
platform: windows
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
type: bug
Comments
fmeum
changed the title
UnsatisfiedLinkError with --experimental_remote_cache_compressionUnsatisfiedLinkError with --experimental_remote_cache_compression on Windows
wilwell
added
team-OSS
|
Looks like it failed to load the zstd JNI library defined at https://cs.opensource.google/bazel/bazel/+/master:third_party/zstd-jni/zstd-jni.BUILD;l=2 Not sure if this is only a remote execution issue. |
|
No, I think we didn't verity it on Windows. |
|
I can confirm that zstd is broken on windows and causes bazel 5.3.0 to crash. We tried to migrate our packages and held off because of this |
cha5on
added a commit
to cha5on/bazel
that referenced
this issue
Sep 17, 2022
Sandboxing on Windows is more limited than on other platforms, so two jni_md.h headers were ending up in the include path. This resulted in the wrong jni_md.h header being used on Windows, which meant that the JNIEXPORT macro was not being set to actually export symbols appropriately on Windows. This caused any attempts to use zstd on windows, whether for http_archive, gRPC cache compression, etc. to result in an UnsatisfiedLinkError being thrown. Change to use a similar method as the main bazel jni stuff, which is to copy the jni.h and jni_md.h headers over. This prevents accidentally picking up a header from the wrong architecture. Relates to bazelbuild#16041
Closed
cha5on
added a commit
to cha5on/bazel
that referenced
this issue
Sep 20, 2022
Sandboxing on Windows is more limited than on other platforms, so two jni_md.h headers were ending up in the include path. This resulted in the wrong jni_md.h header being used on Windows, which meant that the JNIEXPORT macro was not being set to actually export symbols appropriately on Windows. This caused any attempts to use zstd on windows, whether for http_archive, gRPC cache compression, etc. to result in an UnsatisfiedLinkError being thrown. Change to use a similar method as the main bazel jni stuff, which is to copy the jni.h and jni_md.h headers over. This prevents accidentally picking up a header from the wrong architecture. Relates to bazelbuild#16041
cha5on
added a commit
to cha5on/bazel
that referenced
this issue
Sep 20, 2022
meteorcloudy
added
P2
cha5on
added a commit
to cha5on/bazel
that referenced
this issue
Sep 20, 2022
copybara-service bot
pushed a commit
that referenced
this issue
Sep 21, 2022
Sandboxing on Windows is more limited than on other platforms, so two jni_md.h headers were ending up in the include path. This resulted in the wrong jni_md.h header being used on Windows, which meant that the JNIEXPORT macro was not being set to actually export symbols appropriately on Windows. This caused any attempts to use zstd on windows, whether for http_archive, gRPC cache compression, etc. to result in an UnsatisfiedLinkError being thrown. Change to use a similar method as the main bazel jni stuff, which is to copy the jni.h and jni_md.h headers over. This prevents accidentally picking up a header from the wrong architecture. Relates to #16041 Signed-off-by: Sunil Gowroji <sgowroji@google.com>
copybara-service bot
pushed a commit
that referenced
this issue
Sep 21, 2022
Sandboxing on Windows is more limited than on other platforms, so two jni_md.h headers were ending up in the include path. This resulted in the wrong jni_md.h header being used on Windows, which meant that the JNIEXPORT macro was not being set to actually export symbols appropriately on Windows. This caused any attempts to use zstd on windows, whether for http_archive, gRPC cache compression, etc. to result in an UnsatisfiedLinkError being thrown. Change to use a similar method as the main bazel jni stuff, which is to copy the jni.h and jni_md.h headers over. This prevents accidentally picking up a header from the wrong architecture. Relates to #16041 Closes #16293. PiperOrigin-RevId: 475839895 Change-Id: Ia5569c50c8764699abe9858207a256b921980b92
|
#16293 is merged, I assume this is fixed, so closing now, feel free to reopen if you still see the issue. |
aiuto
pushed a commit
to aiuto/bazel
that referenced
this issue
Oct 12, 2022
Sandboxing on Windows is more limited than on other platforms, so two jni_md.h headers were ending up in the include path. This resulted in the wrong jni_md.h header being used on Windows, which meant that the JNIEXPORT macro was not being set to actually export symbols appropriately on Windows. This caused any attempts to use zstd on windows, whether for http_archive, gRPC cache compression, etc. to result in an UnsatisfiedLinkError being thrown. Change to use a similar method as the main bazel jni stuff, which is to copy the jni.h and jni_md.h headers over. This prevents accidentally picking up a header from the wrong architecture. Relates to bazelbuild#16041 Signed-off-by: Sunil Gowroji <sgowroji@google.com>
aiuto
pushed a commit
to aiuto/bazel
that referenced
this issue
Oct 12, 2022
Relates to bazelbuild#16041 Partial commit for third_party/*, see bazelbuild#16293. Signed-off-by: Sunil Gowroji <sgowroji@google.com>
aiuto
pushed a commit
to aiuto/bazel
that referenced
this issue
Oct 12, 2022
Sandboxing on Windows is more limited than on other platforms, so two jni_md.h headers were ending up in the include path. This resulted in the wrong jni_md.h header being used on Windows, which meant that the JNIEXPORT macro was not being set to actually export symbols appropriately on Windows. This caused any attempts to use zstd on windows, whether for http_archive, gRPC cache compression, etc. to result in an UnsatisfiedLinkError being thrown. Change to use a similar method as the main bazel jni stuff, which is to copy the jni.h and jni_md.h headers over. This prevents accidentally picking up a header from the wrong architecture. Relates to bazelbuild#16041 Closes bazelbuild#16293. PiperOrigin-RevId: 475839895 Change-Id: Ia5569c50c8764699abe9858207a256b921980b92
aiuto
pushed a commit
to aiuto/bazel
that referenced
this issue
Oct 12, 2022
Relates to bazelbuild#16041 Partial commit for third_party/*, see bazelbuild#16293. Signed-off-by: Sunil Gowroji <sgowroji@google.com>
aiuto
pushed a commit
to aiuto/bazel
that referenced
this issue
Nov 14, 2022
Relates to bazelbuild#16041 Partial commit for third_party/*, see bazelbuild#16293. Signed-off-by: Sunil Gowroji <sgowroji@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Description of the bug:
Remote builds with
--experimental_remote_cache_compressioncrash Bazel on Windows with:What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
We reliably hit this on CI for CodeIntelligenceTesting/jazzer#431.
The bazel command we run is:
I don't expect this to be BuildBuddy-specific, but haven't been able to test it with other backends.
Which operating system are you running Bazel on?
Windows
What is the output of
bazel info release?5.3.0rc1
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: