Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

link error: undefined symbol of the EM_JS in EMSDK 3.1.28 #18436

Open
xbcnn opened this issue Dec 28, 2022 · 8 comments
Open

link error: undefined symbol of the EM_JS in EMSDK 3.1.28 #18436

xbcnn opened this issue Dec 28, 2022 · 8 comments

Comments

@xbcnn
Copy link
Contributor

xbcnn commented Dec 28, 2022

I have an EM_JS function defined in individual file and it works just fine before. But recently I upgraded EMSDK to 3.1.28, I received linking error: undefined symbol of the EM_JS function.

I have opened EMCC_DEBUG=1, and got following errors.

profiler:DEBUG: block "JS symbol generation" took 0.391 seconds

wasm-ld: error: CMakeFiles/PRJ_dir/Unity/unity_5_cxx.cxx.o: undefined symbol: THE_EM_JS

I checked the __em_js_xxx symbols existing in another unity_12_cxx.cxx.o file. Why the Binaryen failed to handle it?
How can I debug the Binaryen processing or maybe logs?

cc @sbc100 , any ideas?

@sbc100
Copy link
Collaborator

sbc100 commented Dec 28, 2022

I think this is likely related to the fix for #18370. Basically, after this change EM_JS functions appear like natively defined functions with a leading underscore.

I assume what is happening here is that you are using EM_JS functions from JS code or from object files other than the one in which they are defined... how are you declaring THE_EM_JS ?

Ultimately we might need to reverse that change to add the leading underscore to EM_JS functions if this effects many folks.

@sbc100
Copy link
Collaborator

sbc100 commented Dec 28, 2022

@kleisauke was also effect my this issue (which I'm guessing is the extra leading underscore.

@kleisauke
Copy link
Collaborator

PR #18391 was landed as commit a742129 after Emscripten 3.1.28 was released. It's only available in the tip-of-tree build within emsdk at the time of writing.

Perhaps the issue is related to the LLD_REPORT_UNDEFINED change? FWIW, the Emscripten port of libffi removed the need of -sLLD_REPORT_UNDEFINED=0 with commit hoodmane/libffi-emscripten@d1798d8 (i.e. by implementing a native wrapper function).

@sbc100
Copy link
Collaborator

sbc100 commented Dec 28, 2022

Ah yes, in that case this must be related instead to #16003.

With this change all direct callers of EM_JS functions either need to exist in the same object file where it is defined, or they need to define their own __attribute__(import_name('...')) when they declare it.

@xbcnn
Copy link
Contributor Author

xbcnn commented Dec 28, 2022

I assume what is happening here is that you are using EM_JS functions from JS code or from object files other than the one in which they are defined... how are you declaring THE_EM_JS ?

Yes. I use the EM_JS function in several other source files with extern "C" specifier and the exact name(no leading underscore) and parameters in the EM_JS.

@sbc100
Copy link
Collaborator

sbc100 commented Dec 29, 2022

#16003 did indeed lead to those symbols being mangled with a leading underscore. However #18438 reverses that so that shouldn't be needed (assuming #18438 lands).

@xbcnn
Copy link
Contributor Author

xbcnn commented Dec 29, 2022

That's nice! So I suppose it should be available in 3.1.29. #

@sbc100
Copy link
Collaborator

sbc100 commented Dec 29, 2022

Yes, 3.1.29 should have the same behaviour as 3.1.28.. the change in questions was never part of a release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants