build: --disable-single-executable-application results in link failure #51730
Labels
build
Issues and PRs related to build files or the CI.
single-executable
Issues and PRs related to single-executable applications
Comments
mscdex
added
build
|
I think we could just disable the discovery of SEA in the configuration, the code could be compiled in just fine (so some ifdef guards can be lifted to make it compile at least). Unless it's somehow necessary to avoid linking postject into the binary. |
targos
pushed a commit
that referenced
this issue
Mar 7, 2024
Previously it would not compile if the build is configured with --disable-single-executable-application because we use directives to exclude the definition of SEA-related code completely. This patch changes them so that the SEA code are still compiled and internals can still check whether the executable is an SEA. The executable would not try to load the SEA blob at all if SEA is disabled. If future modifications to the C++ code attempt to load the SEA blob when SEA is disabled, UNREACHABLE() would be raised. If user attempt to generate the SEA blob with --experimental-sea-config with an executable that disables SEA, they would get an error. PR-URL: #51808 Fixes: #51730 Reviewed-By: Tobias Nießen <tniessen@tnie.de>
richardlau
pushed a commit
that referenced
this issue
Mar 25, 2024
Previously it would not compile if the build is configured with --disable-single-executable-application because we use directives to exclude the definition of SEA-related code completely. This patch changes them so that the SEA code are still compiled and internals can still check whether the executable is an SEA. The executable would not try to load the SEA blob at all if SEA is disabled. If future modifications to the C++ code attempt to load the SEA blob when SEA is disabled, UNREACHABLE() would be raised. If user attempt to generate the SEA blob with --experimental-sea-config with an executable that disables SEA, they would get an error. PR-URL: #51808 Fixes: #51730 Reviewed-By: Tobias Nießen <tniessen@tnie.de>
richardlau
pushed a commit
that referenced
this issue
Mar 25, 2024
Previously it would not compile if the build is configured with --disable-single-executable-application because we use directives to exclude the definition of SEA-related code completely. This patch changes them so that the SEA code are still compiled and internals can still check whether the executable is an SEA. The executable would not try to load the SEA blob at all if SEA is disabled. If future modifications to the C++ code attempt to load the SEA blob when SEA is disabled, UNREACHABLE() would be raised. If user attempt to generate the SEA blob with --experimental-sea-config with an executable that disables SEA, they would get an error. PR-URL: #51808 Fixes: #51730 Reviewed-By: Tobias Nießen <tniessen@tnie.de>
rdw-msft
pushed a commit
to rdw-msft/node
that referenced
this issue
Mar 26, 2024
Previously it would not compile if the build is configured with --disable-single-executable-application because we use directives to exclude the definition of SEA-related code completely. This patch changes them so that the SEA code are still compiled and internals can still check whether the executable is an SEA. The executable would not try to load the SEA blob at all if SEA is disabled. If future modifications to the C++ code attempt to load the SEA blob when SEA is disabled, UNREACHABLE() would be raised. If user attempt to generate the SEA blob with --experimental-sea-config with an executable that disables SEA, they would get an error. PR-URL: nodejs#51808 Fixes: nodejs#51730 Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
At least v18.x and by the looks of it, everything since
Platform
No response
Subsystem
No response
What steps will reproduce the bug?
Configuring with
--disable-single-executable-applicationresults in a failed build during the final build steps because the functionality is always being referenced regardless of compile-time configuration and gives an error about no_register_sea.Additionally I believe I saw some compiled test failures that happened after the above failures, so it seems like there is even more stuff broken with that configuration.
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior? Why is that the expected behavior?
No response
What do you see instead?
Additional information
No response
The text was updated successfully, but these errors were encountered: