You are my hero :) On Wednesday, 14 September 2022 at 20:40:35 UTC+2 [email protected] wrote:
> Looks promising: https://github.com/emscripten-core/emscripten/pull/17854 > > This depends on a small llvm linker change but otherwise seems to work > fine! > > On Tue, Sep 13, 2022 at 8:12 AM Floh <[email protected]> wrote: > >> > How/where are you calling these functions? >> >> Yes, it's all EM_JS in STB-style single-file C libraries (for instance: >> https://github.com/floooh/sokol/blob/4238be9d53f7a817f7ddf1b8d10560142052c6c7/sokol_app.h#L4519-L4528 >> ) >> >> ...if I would have to distribute a separate .js file with the header it >> would kinda defeat the whole idea of single-file C libraries (and I would >> also need to add Emscripten-specific build instructions). >> >> >... we need to add some kind of dependency mechanism for EM_ASM/EM_JS >> user code >> >> I think this would be the best solution. Maybe it could work similar like >> that new EM_IMPORT macro? (I just found this, don't know what it actually >> does. >> >> >> https://github.com/emscripten-core/emscripten/blob/main/system/include/emscripten/em_macros.h >> >> ...so somewhere in my header I could have a list of all Emscripten >> library functions like this: >> >> EM_JS_DEPS('withStackSave', 'allocateUTF8OnStack', 'UTF8ToString') >> >> Cheers! >> -Floh. >> On Tuesday, 13 September 2022 at 15:34:15 UTC+2 [email protected] wrote: >> >>> On Sat, Sep 10, 2022 at 10:36 AM Floh <[email protected]> wrote: >>> >>>> PS: also I just noticed that allocateUTF8OnStack is on your list of >>>> 'legacy functions', but calling this works just fine in my code. I guess >>>> those are pulled in from some library_*.js that's linked into my code? >>>> >>>> What's the lowest level set of stack helper functions that won't go >>>> away? Is withStackSave(), stackAlloc() and stringToUTF8() guaranteed at >>>> least? >>>> >>> >>> The hope is that we can move away from including any code that is not >>> explicitly needed, and not include any of these functions by default. >>> >>> How/where are you calling these functions? I assume it is >>> something like EM_JS or EM_ASM, since if you were doing it in a JS library >>> then you could add explicitly dependencies. >>> >>> If you are indeed using EM_ASM/EM_JS and expecting to be able to call >>> library functions then it sounds like we need to add some kind of >>> dependency mechanism for EM_ASM/EM_JS user code. >>> >>> Alternatively we could use some kind of analysis of the EM_JS/EM_ASM >>> strings.. perhaps we could just do a dumb conservative string scanner, or >>> use a JS parser to find any used symbols. >>> >>> >>>> On Saturday, 10 September 2022 at 19:27:10 UTC+2 Floh wrote: >>>> >>>>> I just noticed that I had two remaining calls to ccall() where I used >>>>> the string argument marshalling feature (in all other cases I call >>>>> functions on the C side directly). I have those cases now replaced with >>>>> (essentially) "withStackSave(() => { ... allocateUTF8OnStack() ... }" >>>>> >>>>> Is this "kosher"? (I'm aware of the risk that these functions may go >>>>> away one day). >>>>> >>>>> I don't want to impose specific compiler flags (like LEGACY_RUNTIME) >>>>> on my library users, that's why I had to replace ccall() (unless there's >>>>> a >>>>> another way to inject ccall into the code than through compiler options?). >>>>> >>>>> It would be nice to have a guaranteed set of these low level C interop >>>>> functions btw (like this withStackSave, allocateUTF8OnStack stuff). >>>>> >>>>> Cheers! >>>>> -Floh. >>>>> >>>>> On Tuesday, 6 September 2022 at 19:35:05 UTC+2 Shlomi Fish wrote: >>>>> >>>>>> On Tue, 6 Sep 2022 09:06:27 -0700 >>>>>> "'Sam Clegg' via emscripten-discuss" <[email protected]> >>>>>> wrote: >>>>>> >>>>>> > Starting with 2.1.21, in order to make the default output size >>>>>> smaller some >>>>>> > runtime functions are transitioning to library functions. In debug >>>>>> builds, >>>>>> > if you try to use these functions, you should see an actionable >>>>>> warning. >>>>>> > >>>>>> > From the changelog: >>>>>> > >>>>>> >>>>>> Thanks for the warning, Sam! >>>>>> >>>>>> > - The `LEGACY_RUNTIME` setting is no longer enabled by default. If >>>>>> you use >>>>>> > any >>>>>> > of these legacy runtime functions (except in library code with >>>>>> explicit >>>>>> > >>>>>> > dependencies) then you would need to set `LEGACY_RUNTIME` on the >>>>>> command >>>>>> > line >>>>>> > or add the ones you need to `DEFAULT_LIBRARY_FUNCS_TO_INCLUDE`: >>>>>> > >>>>>> > - addFunction >>>>>> > >>>>>> > - removeFunction >>>>>> > >>>>>> > - allocate >>>>>> > >>>>>> > - AsciiToString >>>>>> > >>>>>> > - stringToAscii >>>>>> > >>>>>> > - UTF16ToString >>>>>> > >>>>>> > - stringToUTF16 >>>>>> > >>>>>> > - lengthBytesUTF16 >>>>>> > >>>>>> > - UTF32ToString >>>>>> > >>>>>> > - stringToUTF32 >>>>>> > >>>>>> > - lengthBytesUTF32 >>>>>> > >>>>>> > - allocateUTF8 >>>>>> > >>>>>> > - allocateUTF8OnStack >>>>>> > >>>>>> > - writeStringToMemory >>>>>> > >>>>>> > - writeArrayToMemory >>>>>> > >>>>>> > - writeAsciiToMemory >>>>>> > >>>>>> > - intArrayFromString >>>>>> > >>>>>> > - intArrayToString >>>>>> > >>>>>> > - warnOnce >>>>>> > >>>>>> > - ccall >>>>>> > >>>>>> > - cwrap >>>>>> > >>>>>> > Although this is technically a breaking change for those who use >>>>>> these >>>>>> > >>>>>> > functions, there are assertions in debug builds that catch such >>>>>> usages >>>>>> > and >>>>>> > direct towards how to fix the issue. >>>>>> > >>>>>> > I hope this change is not too disruptive and overall a move in the >>>>>> right >>>>>> > direction. >>>>>> > >>>>>> > cheers, >>>>>> > sam >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Shlomi Fish https://www.shlomifish.org/ >>>>>> Chuck Norris/etc. Facts - >>>>>> https://www.shlomifish.org/humour/bits/facts/ >>>>>> >>>>>> If Botticelli were alive today, he’d be working for Vogue. >>>>>> — https://en.wikiquote.org/wiki/Peter_Ustinov >>>>>> >>>>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/emscripten-discuss/39749284-d7df-4e03-aea7-83362d5ef36cn%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/emscripten-discuss/39749284-d7df-4e03-aea7-83362d5ef36cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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 [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/d825b52e-71bd-497e-acad-06e4d3aabd70n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/d825b52e-71bd-497e-acad-06e4d3aabd70n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/50d85776-9521-4f51-a8d9-633a658f6345n%40googlegroups.com.
