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.
<!--
Before submitting a PR, please read http://deno.land/manual/contributing
1. Give the PR a descriptive title.
Examples of good title:
- fix(std/http): Fix race condition in server
- docs(console): Update docstrings
- feat(doc): Handle nested reexports
Examples of bad title:
- fix #7123
- update docs
- fix bugs
2. Ensure there is a related issue and it is referenced in the PR text.
3. Ensure there are tests that cover the changes.
4. Ensure `cargo test` passes.
5. Ensure `./tools/format.js` passes without changing files.
6. Ensure `./tools/lint.js` passes.
-->
Fixes the error reported in #16304.
> = note:
/usr/bin/ld:/home/abotella/Projects/deno/cli/generated_symbol_exports_list_linux.def:1:
syntax error in dynamic list
collect2: error: ld returned 1 exit status
This was caused by the format of the symbols list on Linux being
malformed (as the error implies).
The format is documented in ld's
[VERSION](https://sourceware.org/binutils/docs/ld/VERSION.html) as well
as:
> --export-dynamic-symbol-list=file
Specify a --export-dynamic-symbol for each pattern in the
file. The format of the file is the same as the version node
without scope and node name. See VERSION for more
information.
Previously, the format for the Linux symbols list was simply a list of
symbols, now it follows the format:
```
{ symbol_name_a; ...; symbol_name_z };
```
Follow-up to #16208.
- Refactors build.rs behaviour to use `-exported_symbols_list` /
`--export-dynamic-symbol-list`
- Since all build systems now rely on a symbols list file, I have added
`generate_exported_symbols_list`, which derives the symbol list file
depending on the platform, which makes `tools/napi/generate_link_win.js`
redundant.
- Fixes a missed instance of `i8` being used instead of `c_char`
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Changes introduced in #13633 have broken the ability to compile for
linux/aarch64 - specifically the use of a `i8` as a char type, which is
an `u8` on linux/aarch64.
This PR:
- Replaces instances of `i8` with the architecture-aware wrapper type
`c_char`
- Skips the use of `--export-dynamic-symbol` on linux-aarch64, because
the target environments often rely on older libc/binutils versions
The current location was causing failures during v1.26.1 publication.
<!--
Before submitting a PR, please read http://deno.land/manual/contributing
1. Give the PR a descriptive title.
Examples of good title:
- fix(std/http): Fix race condition in server
- docs(console): Update docstrings
- feat(doc): Handle nested reexports
Examples of bad title:
- fix #7123
- update docs
- fix bugs
2. Ensure there is a related issue and it is referenced in the PR text.
3. Ensure there are tests that cover the changes.
4. Ensure `cargo test` passes.
5. Ensure `./tools/format.js` passes without changing files.
6. Ensure `./tools/lint.js` passes.
-->
Currently, we use `-rdynamic` for exporting Node API symbols to the
symbol table. `-rdynamic` will export *all* symbols, that means
previously unused functions will not be optimized away introducing a lot
of binary bloat.
This patch uses `-exported_symbol` and `--export-dynamic-symbol` link
flags (not as universal as `-rdynamic`) to only mark Node API symbols to
be put in the dynamic symbol table.
This PR implements the NAPI for loading native modules into Deno.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: DjDeveloper <43033058+DjDeveloperr@users.noreply.github.com>
Co-authored-by: Ryan Dahl <ry@tinyclouds.org>
This commits moves implementation of net related APIs available on "Deno"
namespace to "deno_net" extension.
Following APIs were moved:
- Deno.listen()
- Deno.connect()
- Deno.listenTls()
- Deno.serveHttp()
- Deno.shutdown()
- Deno.resolveDns()
- Deno.listenDatagram()
- Deno.startTls()
- Deno.Conn
- Deno.Listener
- Deno.DatagramConn
This commit renames "JsRuntime::execute" to "JsRuntime::execute_script". Additionally
same renames were applied to methods on "deno_runtime::Worker" and
"deno_runtime::WebWorker".
A new macro was added to "deno_core" called "located_script_name" which
returns the name of Rust file alongside line no and col no of that call site.
This macro is useful in combination with "JsRuntime::execute_script"
and allows to provide accurate place where "one-off" JavaScript scripts
are executed for internal runtime functions.
Co-authored-by: Nayeem Rahman <nayeemrmn99@gmail.com>
This speeds up incremental rebuild when only touching JS files by 30%
compared to #10786.
Rebuild time after touch 01_broadcast_channel.js:
main: run 1 49.18s, run 2 50.34s
#10786: run 1 43.12s, run 2 43.19s
this + #10786: run 1 30.30s, run 2 30.95s
Even if bootstrapping the JS runtime is low level, it's an abstraction leak of
core to require users to call `Deno.core.ops()` in JS space.
So instead we're introducing a `JsRuntime::sync_ops_cache()` method,
once we have runtime extensions a new runtime will ensure the ops
cache is setup (for the provided extensions) and then loading/unloading
plugins should be the only operations that require op cache syncs
