Skip to content

Missing dso_handle #7811

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

Closed
Mintyboi opened this issue Jan 4, 2019 · 3 comments
Closed

Missing dso_handle #7811

Mintyboi opened this issue Jan 4, 2019 · 3 comments

Comments

@Mintyboi
Copy link

Mintyboi commented Jan 4, 2019

@kripken I hit into this error when running my build.

external function '___dso_handle' is missing. perhaps a side module was not linked in? if this symbol was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=1 in the environment

This is because after setting EXPORT_ALL to false in #7371 , this function gets excluded in

if ((EXPORT_ALL || (finalName in EXPORTED_FUNCTIONS)) && !noExport) {

I'm not sure how to reproduce this issue in a smaller test case. However, this function appears to be a standard library function that I am not explicit using.
Do you think it make sense to add it into the shared.Settings.EXPORTED_FUNCTIONS in emcc.py? And if so under which conditions do you think it falls best under

@kripken
Copy link
Member

kripken commented Jan 4, 2019

I think we need to understand that better first. What uses it in your codebase? If you can't share the code, can investigate that in llvm IR using llvm-dis.

@pmp-p
Copy link
Contributor

pmp-p commented Feb 1, 2019

Hi, i get the same when using some various combinations and linking with -ldl for dlopen/ffi goals

only -s EXPORT_ALL=1 -ldl looks valid
https://gist.github.com/pmp-p/68b823a6149d2d6f707cda0a35b0a0dd#file-build-sh

test conditions :
PATH += /opt/sdk/emsdk/clang/e1.38.25_64bit
PATH += /opt/sdk/emsdk/node/8.9.1_64bit/bin
PATH += /opt/sdk/emsdk/emscripten/1.38.25

@Mintyboi
Copy link
Author

Sorry for the late update.
I managed to reproduce this issue in a small testapp (using a fastcomp build, 1.39.6-fastcomp) by using a thread_local static variable and setting the profiling flag in my build.

However, because I'm not seeing this in LLVM backend (1.39.6), I'll be closing this thread.

Thanks to all who tried helping!

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