musl libc updated to v1.2.2

[Sam Clegg]

Yesterday I landed the update to musl v1.2.2: https://github.com/emscripten-core/emscripten/pull/13006

This is a fairly large change so we decided that next emscripten release will bump the version 3.0.0.

If you are interested in helping us test this new version before we release it it would be great if you could try installing the `tot` version of emsdk which now contains this new version musl (`./emsdk install tot`).   We are keen to find and fix any issues that might arise from this change.

cheers,

sam

[Shlomi Fish]

Hi Sam!

On Wed, 10 Nov 2021 08:33:21 -0800
"'Sam Clegg' via emscripten-discuss" <emscripte...@googlegroups.com>
wrote:

Tried it: https://github.com/emscripten-core/emsdk/issues/928 - it is
https://en.wiktionary.org/wiki/DOA . :(.
> cheers,
> sam
>



--

Shlomi Fish https://www.shlomifish.org/
Humanity - Parody of Modern Life - https://shlom.in/humanity

Unix was not designed to stop you from doing stupid things, because that would
also stop you from doing clever things.
— Doug Gwyn ( https://en.wikiquote.org/wiki/Unix )

Please reply to list if it's a mailing list post - https://shlom.in/reply .

[Floh]

I'm getting the following linker errors in my sokol-samples project:

5x:

wasm-ld: error: /...cache/sysroot/lib/wasm32-emscripten/lto/libc.a(exp2f_data.o): undefined symbol: __exp2f_data

8x:

wasm-ld: error: /...cache/sysroot/lib/wasm32-emscripten/lto/libc.a(exp_data.o): undefined symbol: __exp_data

Full wasm-ld command line:

em++: error: '/Users/floh/projects/fips-sdks/emsdk/upstream/bin/wasm-ld -o /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-ninja-release/modplay-sapp.wasm sapp/CMakeFiles/modplay-sapp.dir/modplay-sapp.c.obj libs/sokol/libsokol.a fips-libmodplug_libmodplug/liblibmodplug.a -L/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto -lGL-webgl2 -lal -lhtml5 -lstubs -lc -lcompiler_rt -lc++-noexcept -lc++abi-noexcept -lemmalloc -lc_rt_wasm -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --import-undefined --strip-debug --export-if-defined=main --export-if-defined=stackSave --export-if-defined=stackRestore --export-if-defined=stackAlloc --export-if-defined=__wasm_call_ctors --export-if-defined=__errno_location --export-if-defined=malloc --export-if-defined=free --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-table -z stack-size=5242880 --initial-memory=33554432 --no-entry --max-memory=2147483648 --global-base=1024' failed (returned 1)

...and the em++ command line:

/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/em++ -s DISABLE_EXCEPTION_CATCHING=1  -fno-exceptions -fno-rtti -std=c++11 -fstrict-aliasing -Wall -Wno-multichar -Wextra -Wno-unknown-pragmas -Wno-ignored-qualifiers -Wno-long-long -Wno-overloaded-virtual -Wno-deprecated-writable-strings -Wno-unused-volatile-lvalue -Wno-inconsistent-missing-override -Wno-warn-absolute-paths -Wno-expansion-to-defined  -flto -O3 -DNDEBUG -s DISABLE_EXCEPTION_CATCHING=1  --memory-init-file 0 -s INITIAL_MEMORY=33554432 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s NO_EXIT_RUNTIME=1 -s ALLOW_MEMORY_GROWTH=1 -s USE_WEBGL2=1 -s "MALLOC='emmalloc'" -s NO_FILESYSTEM=1 -s WASM=1  --shell-file /Users/floh/projects/sokol-samples/webpage/shell.html -O3  -flto  --closure 1 -s ASSERTIONS=0 sapp/CMakeFiles/modplay-sapp.dir/modplay-sapp.c.obj -o /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-ninja-release/modplay-sapp.html  libs/sokol/libsokol.a  fips-libmodplug_libmodplug/liblibmodplug.a

Investigating now, I think the most likely culprit is libmodplug (a MOD player library).

Should I open a separate github ticket, or append this type of feedback to the PR?

Cheers,

-Andre.

[Floh]

PS: my other WASM projects appear to work fine (the home computer emulators here: https://floooh.github.io/tiny8bit/, and the Z80 and 6502 netlist simulations: https://floooh.github.io/visualz80remix/, https://floooh.github.io/visual6502remix/).

[Floh]

These are the related header/source pairs in MUSL, and it seems that these are new (didn't exist in the stable SDK):

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/src/math/exp_data.h

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/src/math/exp_data.c

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/src/math/exp2f_data.h

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/src/math/exp2f_data.c

When listing the libc.a symbols in the emscripten cache with llvm-nm I can see the entry for exp_data but nothing for exp2f_data:

exp_data.o:

-------- D __exp_data

(which is doubly weird, why does exp_data produce a linker error even though it's there, and why isn't exp2f_data anywhere to be found)

...anyway, that's how far I got :)

[Sam Clegg]

On Wed, Nov 10, 2021 at 9:50 PM Shlomi Fish <shl...@shlomifish.org> wrote:

Hi Sam!

On Wed, 10 Nov 2021 08:33:21 -0800
"'Sam Clegg' via emscripten-discuss" <emscripte...@googlegroups.com>
wrote:

> Yesterday I landed the update to musl v1.2.2:
> https://github.com/emscripten-core/emscripten/pull/13006

Thanks for trying.  That issue looks unrelated, and it sounds like you have fix now? 

>
> This is a fairly large change so we decided that next emscripten release
> will bump the version 3.0.0.
>
> If you are interested in helping us test this new version before we release
> it it would be great if you could try installing the `tot` version of emsdk
> which now contains this new version musl (`./emsdk install tot`).   We are
> keen to find and fix any issues that might arise from this change.
>

Tried it: https://github.com/emscripten-core/emsdk/issues/928 - it is
https://en.wiktionary.org/wiki/DOA . :(.
> cheers,
> sam
>



--

Shlomi Fish       https://www.shlomifish.org/
Humanity - Parody of Modern Life - https://shlom.in/humanity

Unix was not designed to stop you from doing stupid things, because that would
also stop you from doing clever things.
    — Doug Gwyn ( https://en.wikiquote.org/wiki/Unix )

Please reply to list if it's a mailing list post - https://shlom.in/reply .

--
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/20211111075036.0c585ee5%40shlomifish.org.

[Sam Clegg]

On Thu, Nov 11, 2021 at 3:02 AM Floh <flo...@gmail.com> wrote:

I'm getting the following linker errors in my sokol-samples project:

5x:

wasm-ld: error: /...cache/sysroot/lib/wasm32-emscripten/lto/libc.a(exp2f_data.o): undefined symbol: __exp2f_data

8x:

wasm-ld: error: /...cache/sysroot/lib/wasm32-emscripten/lto/libc.a(exp_data.o): undefined symbol: __exp_data

Full wasm-ld command line:

em++: error: '/Users/floh/projects/fips-sdks/emsdk/upstream/bin/wasm-ld -o /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-ninja-release/modplay-sapp.wasm sapp/CMakeFiles/modplay-sapp.dir/modplay-sapp.c.obj libs/sokol/libsokol.a fips-libmodplug_libmodplug/liblibmodplug.a -L/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto -lGL-webgl2 -lal -lhtml5 -lstubs -lc -lcompiler_rt -lc++-noexcept -lc++abi-noexcept -lemmalloc -lc_rt_wasm -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --import-undefined --strip-debug --export-if-defined=main --export-if-defined=stackSave --export-if-defined=stackRestore --export-if-defined=stackAlloc --export-if-defined=__wasm_call_ctors --export-if-defined=__errno_location --export-if-defined=malloc --export-if-defined=free --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-table -z stack-size=5242880 --initial-memory=33554432 --no-entry --max-memory=2147483648 --global-base=1024' failed (returned 1)

...and the em++ command line:

/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/em++ -s DISABLE_EXCEPTION_CATCHING=1  -fno-exceptions -fno-rtti -std=c++11 -fstrict-aliasing -Wall -Wno-multichar -Wextra -Wno-unknown-pragmas -Wno-ignored-qualifiers -Wno-long-long -Wno-overloaded-virtual -Wno-deprecated-writable-strings -Wno-unused-volatile-lvalue -Wno-inconsistent-missing-override -Wno-warn-absolute-paths -Wno-expansion-to-defined  -flto -O3 -DNDEBUG -s DISABLE_EXCEPTION_CATCHING=1  --memory-init-file 0 -s INITIAL_MEMORY=33554432 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s NO_EXIT_RUNTIME=1 -s ALLOW_MEMORY_GROWTH=1 -s USE_WEBGL2=1 -s "MALLOC='emmalloc'" -s NO_FILESYSTEM=1 -s WASM=1  --shell-file /Users/floh/projects/sokol-samples/webpage/shell.html -O3  -flto  --closure 1 -s ASSERTIONS=0 sapp/CMakeFiles/modplay-sapp.dir/modplay-sapp.c.obj -o /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-ninja-release/modplay-sapp.html  libs/sokol/libsokol.a  fips-libmodplug_libmodplug/liblibmodplug.a

Investigating now, I think the most likely culprit is libmodplug (a MOD player library).

Should I open a separate github ticket, or append this type of feedback to the PR?

Please open a separate issue, and link to the musl upgrade as the suspected culprit.  Thanks Floh! 

Cheers,

-Andre.

On Wednesday, 10 November 2021 at 17:33:34 UTC+1 s...@google.com wrote:

Yesterday I landed the update to musl v1.2.2: https://github.com/emscripten-core/emscripten/pull/13006

This is a fairly large change so we decided that next emscripten release will bump the version 3.0.0.

If you are interested in helping us test this new version before we release it it would be great if you could try installing the `tot` version of emsdk which now contains this new version musl (`./emsdk install tot`).   We are keen to find and fix any issues that might arise from this change.

cheers,

sam

--

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/692231bc-26f4-4da9-b62f-0d62dea83f4dn%40googlegroups.com.

[Sam Clegg]

On Thu, Nov 11, 2021 at 4:46 AM Floh <flo...@gmail.com> wrote:

These are the related header/source pairs in MUSL, and it seems that these are new (didn't exist in the stable SDK):

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/src/math/exp_data.h

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/src/math/exp_data.c

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/src/math/exp2f_data.h

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/src/math/exp2f_data.c

When listing the libc.a symbols in the emscripten cache with llvm-nm I can see the entry for exp_data but nothing for exp2f_data:

exp_data.o:

-------- D __exp_data

(which is doubly weird, why does exp_data produce a linker error even though it's there, and why isn't exp2f_data anywhere to be found)

...anyway, that's how far I got :)

I suspect LTO is the culprit here.    Does you non-LTO build work?

I think these symbols can get generated at codegen time which can confuse LTO because it likes to know all the symbols needed before running the compiler/LTO.

 

On Thursday, 11 November 2021 at 12:57:06 UTC+1 Floh wrote:

PS: my other WASM projects appear to work fine (the home computer emulators here: https://floooh.github.io/tiny8bit/, and the Z80 and 6502 netlist simulations: https://floooh.github.io/visualz80remix/, https://floooh.github.io/visual6502remix/).

On Thursday, 11 November 2021 at 12:02:12 UTC+1 Floh wrote:

I'm getting the following linker errors in my sokol-samples project:

5x:

wasm-ld: error: /...cache/sysroot/lib/wasm32-emscripten/lto/libc.a(exp2f_data.o): undefined symbol: __exp2f_data

8x:

wasm-ld: error: /...cache/sysroot/lib/wasm32-emscripten/lto/libc.a(exp_data.o): undefined symbol: __exp_data

Full wasm-ld command line:

em++: error: '/Users/floh/projects/fips-sdks/emsdk/upstream/bin/wasm-ld -o /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-ninja-release/modplay-sapp.wasm sapp/CMakeFiles/modplay-sapp.dir/modplay-sapp.c.obj libs/sokol/libsokol.a fips-libmodplug_libmodplug/liblibmodplug.a -L/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto -lGL-webgl2 -lal -lhtml5 -lstubs -lc -lcompiler_rt -lc++-noexcept -lc++abi-noexcept -lemmalloc -lc_rt_wasm -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --import-undefined --strip-debug --export-if-defined=main --export-if-defined=stackSave --export-if-defined=stackRestore --export-if-defined=stackAlloc --export-if-defined=__wasm_call_ctors --export-if-defined=__errno_location --export-if-defined=malloc --export-if-defined=free --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-table -z stack-size=5242880 --initial-memory=33554432 --no-entry --max-memory=2147483648 --global-base=1024' failed (returned 1)

...and the em++ command line:

/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/em++ -s DISABLE_EXCEPTION_CATCHING=1  -fno-exceptions -fno-rtti -std=c++11 -fstrict-aliasing -Wall -Wno-multichar -Wextra -Wno-unknown-pragmas -Wno-ignored-qualifiers -Wno-long-long -Wno-overloaded-virtual -Wno-deprecated-writable-strings -Wno-unused-volatile-lvalue -Wno-inconsistent-missing-override -Wno-warn-absolute-paths -Wno-expansion-to-defined  -flto -O3 -DNDEBUG -s DISABLE_EXCEPTION_CATCHING=1  --memory-init-file 0 -s INITIAL_MEMORY=33554432 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s NO_EXIT_RUNTIME=1 -s ALLOW_MEMORY_GROWTH=1 -s USE_WEBGL2=1 -s "MALLOC='emmalloc'" -s NO_FILESYSTEM=1 -s WASM=1  --shell-file /Users/floh/projects/sokol-samples/webpage/shell.html -O3  -flto  --closure 1 -s ASSERTIONS=0 sapp/CMakeFiles/modplay-sapp.dir/modplay-sapp.c.obj -o /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-ninja-release/modplay-sapp.html  libs/sokol/libsokol.a  fips-libmodplug_libmodplug/liblibmodplug.a

Investigating now, I think the most likely culprit is libmodplug (a MOD player library).

Should I open a separate github ticket, or append this type of feedback to the PR?

Cheers,

-Andre.

On Wednesday, 10 November 2021 at 17:33:34 UTC+1 s...@google.com wrote:

Yesterday I landed the update to musl v1.2.2: https://github.com/emscripten-core/emscripten/pull/13006

This is a fairly large change so we decided that next emscripten release will bump the version 3.0.0.

If you are interested in helping us test this new version before we release it it would be great if you could try installing the `tot` version of emsdk which now contains this new version musl (`./emsdk install tot`).   We are keen to find and fix any issues that might arise from this change.

cheers,

sam

--

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/ff0f0683-9ed5-44b0-b0be-f51267863559n%40googlegroups.com.

[Sam Clegg]

I think this should fix your issue: https://github.com/emscripten-core/emscripten/pull/15497

[Floh]

> I suspect LTO is the culprit here.

That's indeed the issue. Building without LTO works. I'll try to come up with a minimal reproducer, create a github ticket and then see if I can get your PR working with my local emsdk installation :)

[Floh]

I started a github issue here: https://github.com/emscripten-core/emscripten/issues/15506

...unfortunately I haven't been able to create a simple reproducer yet, building a simple test program which calls into one of the exp, exp2 or pow functions appears to work, with or without lto.

[Floh]

Ah... that was simply the optimizer resolving the math code into a constant expression. Reproduction test cases incoming :)

[Sam Clegg]

On Fri, Nov 12, 2021 at 4:10 AM Floh <flo...@gmail.com> wrote:

Ah... that was simply the optimizer resolving the math code into a constant expression. Reproduction test cases incoming :)

Yes, all these LTO issues related to LLVM creating references to symbols during LTO that didn't exist prior.

There has been an upstream LLVM issue open for a while now:  https://bugs.llvm.org/show_bug.cgi?id=44353

Hopefully this change is enough to address them: https://github.com/emscripten-core/emscripten/pull/15497

cheers,

sam

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/dc1badc0-77ea-4f08-85ba-40298631c025n%40googlegroups.com.

[Floh]

Btw Sam, with your last two PRs my sokol samples now build and run fine using the emsdk tot version.

Thanks for the quick fixes :)