summaryrefslogtreecommitdiff
path: root/ext/web/08_text_encoding.js
diff options
context:
space:
mode:
authorLuke Channings <461449+LukeChannings@users.noreply.github.com>2022-10-22 22:41:11 +0100
committerGitHub <noreply@github.com>2022-10-22 23:41:11 +0200
commit45ac6e602da9cd016d4a3b093fd4873b90897f9a (patch)
treef47f5158a3ba6fed7ff0ce45d40e4c1569929be8 /ext/web/08_text_encoding.js
parent8864a1d10fdd515d52fd436fc86af0b72656bfbd (diff)
fix(build) assume a custom compiler will support --export-dynamic-symbol-list linker flag. (#16387)
This PR fixes a regression that caused deno binaries produced by the CI release workflows to be larger than expected. **The problem:** The build script will determine whether the linker supports the `--export-dynamic-symbol-list` flag by looking at the glibc version installed on the system. Ubuntu 20.04 ships with glibc 2.31, which does not support this flag. Upon investigation, I discovered that the CI pipeline does not use the gcc compiler provided by the `build-essential` package, and instead uses *clang-14*, which does support the new flag. **The solution:** Whenever a custom C Compiler is configured, the build script now assumes the compiler supports the `--export-dynamic-symbol-list` flag. This is not always going to be the case (you could use clang-8, for example), but it puts the onus on the user making the override to ensure the compiler has support. This will return deno builds for Linux to their previous size of ~100MB, and also allow builds under older glibc/gcc versions to succeed. If a user is compiling deno with a custom compiler that does not support this new flag, however, their build will fail. I expect this is a rare scenario, however, and suggest we cross that bridge if and when we come to it.
Diffstat (limited to 'ext/web/08_text_encoding.js')
0 files changed, 0 insertions, 0 deletions