configure.ac: setup build tools and register objects
main.c: wrap main with rb_wasm_rt_start to handle asyncify unwinds
tool/m4/ruby_wasm_tools.m4: setup default command based on WASI_SDK_PATH
environment variable. checks wasm-opt which is used for asyncify.
tool/wasm-clangw wasm/wasm-opt: a clang wrapper which replaces real
wasm-opt with do-nothing wasm-opt to avoid misoptimization before
asyncify. asyncify is performed at POSTLINK, but clang linker driver
tries to run optimization by wasm-opt unconditionally. inlining pass
at wasm level breaks asyncify's assumption, so should not optimize
before POSTLIK.
wasm/GNUmakefile.in: wasm specific rules to compile objects
These flags are very wasi-libc version specific, so updating wasi-libc
may break the build. But supporting multiple wasi-libc versions in ruby
doesn't have much benefit because wasi-libc is not installed in most
systems.
The madvise() declaration should always be compiled on Solaris
to check whether the declaration is good on the environment.
For the purpose, the #if line is unnecessary.
(There was also a trivial typo that the #if was not closed
by #endif and the check always failed with preprocessor error.)
SunC
```
"cont.c", line 24: identifier redeclared: madvise
current : function(pointer to char, unsigned int, int) returning int
previous: function(pointer to void, unsigned int, int) returning int : "/usr/include/sys/mman.h", line 232
```
GCC
```
cont.c:24:12: error: conflicting types for 'madvise'
24 | extern int madvise(caddr_t, size_t, int);
| ^~~~~~~
In file included from cont.c:16:
/usr/include/sys/mman.h:232:12: note: previous declaration of 'madvise' was here
232 | extern int madvise(void *, size_t, int);
| ^~~~~~~
```
On Solaris, madvise(3C) is NOT defined for SUS (XPG4v2) or later,
but MADV_* macros are defined when __EXTENSIONS__ is defined.
This may cause compile error on Solaris 10 with GCC when
"-Werror=implicit-function-declaration" and "-D_XOPEN_SOURCE=600"
are added by configure.
This allows easy differentiation between ABI incompatible platforms like MSWIN64 and MSVCRT-based MINGW32.
This also implicates a distinct rubygem platform which is also "x64-mingw-ucrt".
Although the term "mingw32" is the OS-part for 64 bit systems as well, the "32" is misleading and confusing for many users.
Therefore the new platform string drops the "32" from the OS part to just "mingw".
This conforms to the common practice of windows platform testing per RUBY_PLATFORM=~/mswin|mingw/ .
Find jemalloc header first, then using the found header, try [with
mangle, without mangle] x [no more additional libraries, adding
jemalloc] combination.
It is reported that combination of `--enable-shared --with-jemalloc`
breaks on Debian bullseye (testig). Deeper investigation revealed that
this system's `ld(1)` is patched, to turn `ld --as-needed` on by
default.
This linker flag strips "unnecessary" library dependencies from an
executable. In case of `ruby(1)` (of `--enable-shared`), because
everything is in `libruby.so`, the binary itself doesn't include any
calls to `malloc(3)` at all. So in spite of our explicit `-ljemalloc`
flag, it is ignored. Libc's one is chosen instead.
This is not what we want. Let's force our `ruby(1)` link what we want.
Fixes https://github.com/ruby/ruby/pull/4627
The author would like to acknowledge
Akihiko Odaki <akihiko.odaki@gmail.com> for their contributions.
