Which sysroot libs to use?

[Mark Sibly]

Hi,

I'm writing a little compiler for a new language which will output wasm for browsers and I'd like to be able to link it's wasm output with emscripten wasm output so I can write libraries for it in c/c++.

However, I'm a bit confused about which sysroot libs I should be linking with, in particular, when I try to link with libc-mt.a I get the following error in the browser:

Uncaught (in promise) TypeError: WebAssembly.instantiate(): Import #2 module="wasi_snapshot_preview1" error: module is not an object or function

I don't know much about 'wasi' except it seems to be a 'posix-like' lib for wasm apps that don't run on the web, so I was a bit surprised to get this!

I also tried libc-ww.a thinking 'ww' might be for 'web' or something but same problem, it's looking for wasi.

What exactly are the 'ww' libs? I get 'mt is for multi-threaded and debug is debug but ww? Dit emmalloc vs dlmalloc? Static vs dynamic?

I'll probably get there in the end through trial and error, but any hints would be greatly appreciated!

Bye,

Mark

[Mark Sibly]

OK, making progress I think...

emmalloc is smaller/simpler/maybe-less-efficient version of dlmalloc?

ww is webworker? I'm using posix threads so I should ignore and use mt libs instead?

libc_optz is minimized for size, has no references to wasi?

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/PzwrSOCba6E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/fa9b1c09-c54b-47c7-bf38-d7afcaf57eb6n%40googlegroups.com.

[Sam Clegg]

On Wed, Nov 9, 2022 at 1:41 PM Mark Sibly <mark...@gmail.com> wrote:

OK, making progress I think...

emmalloc is smaller/simpler/maybe-less-efficient version of dlmalloc?

Basically yes.

 

ww is webworker? I'm using posix threads so I should ignore and use mt libs instead?

ww means wasm worker, which is an alternative way to use workers if you don't want pthreads.

 

libc_optz is minimized for size, has no references to wasi?

 libc_optz contains just a few optimized libc files.   You still need libc.a or libc-mt.a.

You can see how the different libraries are built here: https://github.com/emscripten-core/emscripten/blob/main/tools/system_libs.py#L1171-L1174

 

On Thu, Nov 10, 2022 at 10:03 AM Mark Sibly <mark...@gmail.com> wrote:

Hi,

I'm writing a little compiler for a new language which will output wasm for browsers and I'd like to be able to link it's wasm output with emscripten wasm output so I can write libraries for it in c/c++.

However, I'm a bit confused about which sysroot libs I should be linking with, in particular, when I try to link with libc-mt.a I get the following error in the browser:

Uncaught (in promise) TypeError: WebAssembly.instantiate(): Import #2 module="wasi_snapshot_preview1" error: module is not an object or function

I don't know much about 'wasi' except it seems to be a 'posix-like' lib for wasm apps that don't run on the web, so I was a bit surprised to get this!

I also tried libc-ww.a thinking 'ww' might be for 'web' or something but same problem, it's looking for wasi.

What exactly are the 'ww' libs? I get 'mt is for multi-threaded and debug is debug but ww? Dit emmalloc vs dlmalloc? Static vs dynamic?

I'll probably get there in the end through trial and error, but any hints would be greatly appreciated!

Bye,

Mark

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/PzwrSOCba6E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/fa9b1c09-c54b-47c7-bf38-d7afcaf57eb6n%40googlegroups.com.

--

You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAK32ozidQHx_bBH8SMZmn6T9hUV38wQrZYRNFEYV%2BpZ8TvrLNA%40mail.gmail.com.

[Sam Clegg]

On Wed, Nov 9, 2022 at 1:03 PM Mark Sibly <mark...@gmail.com> wrote:

Hi,

I'm writing a little compiler for a new language which will output wasm for browsers and I'd like to be able to link it's wasm output with emscripten wasm output so I can write libraries for it in c/c++.

However, I'm a bit confused about which sysroot libs I should be linking with, in particular, when I try to link with libc-mt.a I get the following error in the browser:

Uncaught (in promise) TypeError: WebAssembly.instantiate(): Import #2 module="wasi_snapshot_preview1" error: module is not an object or function

Where it makes sense in emscripten we use wasi syscalls rather than creating new web-specific ones.   The idea is to maximise compatibility, although in practice emscripten programs almost always depend on some non-wasi syscalls too.

 

I don't know much about 'wasi' except it seems to be a 'posix-like' lib for wasm apps that don't run on the web, so I was a bit surprised to get this!

I also tried libc-ww.a thinking 'ww' might be for 'web' or something but same problem, it's looking for wasi.

What exactly are the 'ww' libs? I get 'mt is for multi-threaded and debug is debug but ww? Dit emmalloc vs dlmalloc? Static vs dynamic?

I'll probably get there in the end through trial and error, but any hints would be greatly appreciated!

Bye,

Mark

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/fa9b1c09-c54b-47c7-bf38-d7afcaf57eb6n%40googlegroups.com.

[Mark Sibly]

Thanks a bunch Sam, that python script should help a lot!

I'm still a bit puzzled about the mysterious wasi calls, it looks like plain libc might have a dependency on some other stuff like wasmfs? I'll keep poking around...

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_wk9J-TJzUWRKn_N1JyyZ6so8ZjFkAGXQ5eV9HGSKrLw%40mail.gmail.com.

[Sam Clegg]

On Wed, Nov 9, 2022 at 5:22 PM Mark Sibly <mark...@gmail.com> wrote:

Thanks a bunch Sam, that python script should help a lot!

I'm still a bit puzzled about the mysterious wasi calls, it looks like plain libc might have a dependency on some other stuff like wasmfs? I'll keep poking around...

libc certainly depends on filesystem stuff.. it depends pretty much all the emscripten syscalls.   wasmfs won't be used by default though (at least not yet). 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAK32ozjoPE%2BUWAwmutpnBsRgNcZQeNYFP2N-MwvY%2B2OcBNSt4w%40mail.gmail.com.

[Mark Sibly]

I think I found the wasi problem. I'd added my own little 'puts' function for testing which, although implemented in javascript, was declared/called from c (although my js version is still called at runtime!) and it looks like this was enough to cause the c 'puts' function to be kept alive. This was ultimately causing wasi_blah.fd_write to be kept alive too. Simply changing the name of my little puts fixed that problem so no more wasi issues for now.

There are still a number of mystery symbols in the final wasm when I link with 'full' libc-mt, but not many now and I suspect they're to do with various compiler settings.