development/deno
development/deno
1
0
Fork 0
mirror of https://github.com/denoland/deno synced 2024-08-25 02:57:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(build) assume a custom compiler will support --export-dynamic-symbol-list linker flag. (#16387)

Browse source 
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.
This commit is contained in:
Luke Channings 2022-10-22 22:41:11 +01:00 committed by GitHub
parent 8864a1d10f
commit 45ac6e602d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
cli/build.rs
View file

@ -361,7 +361,10 @@ fn main() {
#[cfg(target_os = "linux")]
{
let ver = glibc_version::get_version().unwrap();
if ver.major <= 2 && ver.minor < 35 {
// If a custom compiler is set, the glibc version is not reliable.
// Here, we assume that if a custom compiler is used, that it will be modern enough to support a dynamic symbol list.
if env::var("CC").is_err() && ver.major <= 2 && ver.minor < 35 {
println!("cargo:warning=Compiling with all symbols exported, this will result in a larger binary. Please use glibc 2.35 or later for an optimised build.");
println!("cargo:rustc-link-arg-bin=deno=-rdynamic");
} else {