Does -s ERROR_ON_UNDEFINED_SYMBOLS=0 actually works

[Александр Гурьянов]

Hi. I have old project that was compiled with fastcomp. Now I updated
it to upstream, but I have error on link stage.
```
wasm-ld: error: CMakeFiles/bin-obj.dir/AppDelegate.cpp.o: undefined
symbol: typeinfo for EditorScene
wasm-ld: error: CMakeFiles/bin-obj.dir/IAP/IAPManager.cpp.o: undefined
symbol: vtable for IAPPlatformDummy
wasm-ld: error: CMakeFiles/bin-obj.dir/IAP/IAPManager.cpp.o: undefined
symbol: typeinfo for OnlineLevelListScene
wasm-ld: error: CMakeFiles/bin-obj.dir/IAP/IAPManager.cpp.o: undefined
symbol: typeinfo for CommunityScene
wasm-ld: error: CMakeFiles/bin-obj.dir/Scenes/SocialLayer.cpp.o:
undefined symbol: typeinfo for OnlineLevelListLayer
...
wasm-ld: error: too many errors emitted, stopping now (use
-error-limit=0 to see all errors)
shared:ERROR: '/home/caiiiycuk/sdk/emsdk/upstream/bin/wasm-ld
@/tmp/emscripten_ricuunpu.rsp' failed (1)
```

This project have a lot of undefined symbols, and it's ok. For native
I can successfully compile it with
```
set(CMAKE_EXE_LINKER_FLAGS "-Wl,--unresolved-symbols=ignore-all")
```

And it works fine. For web I used fastcomp with -s
ERROR_ON_UNDEFINED_SYMBOLS=0 and it works fine.
But now, I can compile it, event with -s ERROR_ON_UNDEFINED_SYMBOLS=0

[Александр Гурьянов]

*I can't compile it, even with -s ERROR_ON_UNDEFINED_SYMBOLS=0

пн, 27 апр. 2020 г. в 10:15, Александр Гурьянов <caii...@gmail.com>:

[Sam Clegg]

As of today the wasm-ld linker only supports undefined symbols if they are function symbols.   As you can see from the error message the error all relate to data symbols (in this case vtable and typinfo data symbols).    This is because, for function symbols, it is able to include a function import in place of the undefined symbol allowing it to be undefined at link time and yet defined at runtime.   For data symbols there is no logical equivalent.  The best the linker can do is write a zero (or some other constant) in the place of the undefined symbol's address.

I am curious what the native linker does when in order to handle a reference to an undefined data symbol.   I'm assuming it writes zeros, but I would guess that would result in a program that would crash as soon as one of those symbols was accessed?   I'll take a look to see if I can do the same thing in wasm-ld that the native linker would do.    How does the program in question end up being linked into something that doesn't crash?

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/CAKOm%3DVGPWSd7%2ByPVAhBMB3rh8Y1P3vGHRvAx7ey6aG6R_Nob0Q%40mail.gmail.com.

[Александр Гурьянов]

This program is a game, that contains game itself and builtin level
editor. They are tight coupled using raw pointers. Game was designed
in way that in release mode editor is not accessible, it only
available in debug build. But it was using pointers, so for compiler
release and debug build is same on source code level. But it's true
that in release build editor is never called. So, for minify wasm size
I doesn't include editor sources in final build.

[Sam Clegg]

So do you think it would make sense to set the address of any link-time-undefined data symbols to zero in this case?  It seems like the only option.

 

--
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/CAKOm%3DVHmemJV39_y5iFBdzwMkiME7fvMacr559cx5kegBJzKdg%40mail.gmail.com.

[Александр Гурьянов]

I think yes. For me it's very useful, sometimes it easier to remove
some sources from project then trying to compile them for web.

ср, 29 апр. 2020 г. в 03:56, 'Sam Clegg' via emscripten-discuss
<emscripte...@googlegroups.com>:

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