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

is it possible to get stuff from compiler_rt to be in the modules? #9964

Closed
SetLinux opened this issue Dec 5, 2019 · 16 comments
Closed

is it possible to get stuff from compiler_rt to be in the modules? #9964

SetLinux opened this issue Dec 5, 2019 · 16 comments
Labels

Comments

@SetLinux
Copy link

SetLinux commented Dec 5, 2019

i am having an attempt at creating a wasm module from emscripten and then linking it to rust and for the most part it works p good but i tried to do it with "FreeType" and then noticed that when trying to link it in rust i get "undefined symbol : THREW" which if i understand correctly makes sense because such function is only added at the final stages so how can i get such thing to be embedded in the module

@sbc100
Copy link
Collaborator

sbc100 commented Dec 5, 2019

How are you linking the wasm module? compiler-rt, just like libc should be linked into the wasm file.

@SetLinux
Copy link
Author

SetLinux commented Dec 6, 2019

Firstly I compile with the flags "-s MODULAR=1 -s EXPORT_ES6=1 -s LINKABLE=1" then I generate bitcode static file and take that file and link against it

@SetLinux
Copy link
Author

SetLinux commented Dec 6, 2019

It's working fine with C++ projects (linked harfbuzz and Bullet successfully)

@sbc100
Copy link
Collaborator

sbc100 commented Dec 6, 2019

So it sounds like you are not linking at all, basically building a big object file? So that result won't have any libc or copiler-rt of any library as part of it. And then how do you link the resulting library/object? Are you trying to link it with emscripten or with some other linker?

Or are you actually doing a link step to produce that bitcode? I believe that "-s MODULAR=1 -s EXPORT_ES6=1 -s LINKABLE=1" are all link-time only flags that should not be needed if you are just building an object file.. i.e. only effect the linker output, not the compiler output.

@SetLinux
Copy link
Author

SetLinux commented Dec 6, 2019

Oah I see what you mean I used to use these flags on my other emscripten projects so didn't think much of it ; and I am then linking the bitcode file with rust

@sbc100
Copy link
Collaborator

sbc100 commented Dec 6, 2019

I'm not sure how the rust+emscripten thing works. Perhaps @tlively knows more.

But in general emscripten-generated code can end up depending on emscripten's compiler-rt and other core libraries being available at link time.

@SetLinux
Copy link
Author

SetLinux commented Dec 6, 2019

Is there anyway to have this inside the bitcode file ?

@tlively
Copy link
Member

tlively commented Dec 6, 2019

@GreatIndieDeveloper how are you linking Emscripten's output with your rust code? Are you using the wasm32-unknown-emscripten Rust target triple?

@SetLinux
Copy link
Author

SetLinux commented Dec 6, 2019

Nope I am using the wasm32-unknown-unknown and I been able to get C++ libs linking successfully

@tlively
Copy link
Member

tlively commented Dec 6, 2019

Ah, that is not expected to work right now due to a mismatch between the C ABI used by Rust with the wasm32-unknown-unknown target and the actual C ABI used by clang and Emscripten. If you want to link C/C++ objects into your Rust wasm project, you have to use the wasm32-unknown-emscripten Rust target for now.

@SetLinux
Copy link
Author

SetLinux commented Dec 7, 2019

Is there any plans to have this working in the near future ? :) As this would be extremely useful

@SetLinux
Copy link
Author

SetLinux commented Dec 7, 2019

And this is actually a bit weird as I got Bullet linking successfully before

@SetLinux
Copy link
Author

SetLinux commented Dec 7, 2019

With extern C for the interface I will be using and a custom malloc

@SetLinux
Copy link
Author

SetLinux commented Dec 8, 2019

..

@tlively
Copy link
Member

tlively commented Dec 9, 2019

There are plans to resolve the ABI mismatch by introducing a new C ABI that will be used by both Rust and C, but there is a lot of work that will have to happen first, so this is not going to be a short term solution. See WebAssembly/tool-conventions#88 for more details.

@stale
Copy link

stale bot commented Dec 9, 2020

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Dec 9, 2020
@stale stale bot closed this as completed Jan 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants