I think it should be `extern *"C"* int32_t rv_api_1;` on the C++ side, 
otherwise normal mangling rules apply and it's looking up (or, this case, 
declaring) a namespaced variable.

On Wednesday, 26 January 2022 at 19:31:18 UTC [email protected] wrote:

> Is it valid to simply do `extern int32_t rv_api_1;` in C to refer to a 
> rust variable?  Does that address of `rv_api_1` on the C side look correct?
>
> Does `pub static rv_api_1: i32 = 1;` in rust generate a static initializer 
> function or is it simply static memory (like it would be in C/C++)?
>
> Assuming it is generating a ctor then there are a couple of things that 
> could be going on.   Are you sure your static ctors have been run?  i.e. 
> where is your code running?  Is it inside of main?   Disassembling your 
> final binary should show all static ctors being called from the 
> `__wasm_call_ctors` function.
>
> cheers,
> sam
>
>
> On Wed, Jan 26, 2022 at 10:24 AM Александр Гурьянов <[email protected]> 
> wrote:
>
>> Okay, I think I almost did the same in Rust what Alon described. 
>> vanger-rs now compiles as static library (.a) with emscripten triple. I use 
>> this static library to link with original C++ game. So I have *.o files 
>> from vangers, and librusty_vangers.a (which provides rendering on wgpu). I 
>> link them with emcc, and it produce wasm  without any error!
>>
>> Also I do the same with native build - it works fine.
>>
>> However, when I tries to run it fails with assertion. 
>>
>> On RUST side I have the following code:
>> #[no_mangle]
>> pub static rv_api_1: i32 = 1;
>>
>> On C++ side I have the following code:
>> extern int32_t rv_api_1;
>> // ...
>> if(rv_api_1 != 1){
>>         printf("Invalid libvangers_ffi version expected 1, actual %d\n", 
>> rv_api_1);
>>         // abort();
>> }
>>
>> When I run it, I have following output:
>> Invalid libvangers_ffi version expected 1, actual 0
>>
>> For me it looks like static initializer from RUST didn't run. Because if 
>> I comment the abort(); seems integration works fine. Native build works 
>> correctly...
>> Do you have any idea why so?
>>
>> ср, 19 янв. 2022 г. в 00:36, Alon Zakai <[email protected]>:
>>
>>>
>>>
>>> On Fri, Jan 14, 2022 at 11:08 AM Александр Гурьянов <[email protected]> 
>>> wrote:
>>>
>>>> Let's look closer to my case. I ported C++ game Vangers to the web (
>>>> https://www.gamepix.com/play/vangers). Vangers community did big work 
>>>> to integrate vange-rs (rust 3d render, based on wgpu) and Vangers game. It 
>>>> works as follow: 
>>>> 1. Vange-rs provide c ffi interface
>>>> 2. Vange-rs compiled with rust to static library
>>>> 3. Vangers linked with Vanger-rs to executable
>>>>
>>>> Now I want to port  vangers + (vange-rs render) to the web. wgpu didn't 
>>>> support wasm32-unknown-emscripten, I added experimental support for 
>>>> emscripten and it works. BUT, wgpu is developing to fast, so my changes 
>>>> become outdated very fast :) 
>>>>
>>>> When I implement support for emscripten, I only disabling 
>>>> wasm32-unknown rules and uses native code paths everywhere. So, it's 
>>>> little 
>>>> bit strange, to work with emscripten you need to disable workarounds for 
>>>> wasm32. emscripten emulates native platform, so code that correctly uses 
>>>> posix system should work also in emscripten.
>>>>
>>>> Maybe there is any way to just use native static library and link it 
>>>> with emscripten? Like this:
>>>> 1. Compile vange-rs static library (with native triple)
>>>> 2. Compile vangers project with emscripten
>>>> 3. Link 1+2 with emscripten 
>>>>
>>>>
>>> (1) would compile to x86, though, I think? We have to have wasm to link 
>>> with emscripten.
>>>  
>>>
>>>> for (1.) I can't use emscripten triple because of #[cfg] rules for 
>>>> wasm32 target, they select wrong code path (non-native).
>>>>
>>>>
>>> Hmm, I don't know enough rust to know what fixing that would mean...
>>>
>>> Overall for an emscripten port I think we would want to use a native 
>>> build as much as possible? That is, ideally you would *not* use 
>>> vange-rs/WebGPU, but one of the native rendering paths (OpenGL of some 
>>> flavor? Or perhaps they have Dawn/WebGPU support?). And you would need to 
>>> tell rust to use the emscripten triple while doing so.
>>>
>>> That should work, in theory. If it doesn't and Rust has some issues with 
>>> how it invokes emcc to link, then the workaround could be what I mentioned 
>>> for Zig and C before: get Rust to link to a static library, and then run 
>>> emcc manually on that.
>>>
>>> (Alternatively, in theory someone could look into supporting 
>>> wasm-bindgen + emscripten.)
>>>
>>> - Alon
>>>  
>>>
>>>> пт, 14 янв. 2022 г. в 07:54, Alon Zakai <[email protected]>:
>>>>
>>>>> Thanks, good to know at least 2 people would read a post about this :) 
>>>>> I'll try to find time for it.
>>>>>
>>>>> About Rust, I haven't had time to look into it yet. My general hope is 
>>>>> that the same model as for C and Zig could work:
>>>>>
>>>>> 1. Tell Rust to use the emscripten wasm triple.
>>>>> 2. Tell Rust to compile to object files (or a static library, 
>>>>> basically), and *not* to link them.
>>>>> 3. The user runs emcc on those object files, linking them.
>>>>>
>>>>> The nice thing in this model is that C/Zig/Rust does not need to be 
>>>>> aware of emcc at all here (aside from telling LLVM to use the emscripten 
>>>>> triple). And it's easy to do this, at least in C and Zig (although there 
>>>>> are some subtle ABI questions).
>>>>>
>>>>> This is actually the main thing I wanted to do before writing the post 
>>>>> - ideally I'd have a Rust demo alongside C and Zig - so if someone 
>>>>> figures 
>>>>> that out, let me know!
>>>>>
>>>>> - Alon
>>>>>
>>>>>
>>>>> On Thu, Jan 13, 2022 at 2:06 AM Александр Гурьянов <[email protected]> 
>>>>> wrote:
>>>>>
>>>>>> +1 for blog post. Not clear how I can use it with rust, e.g. can I 
>>>>>> compile static lib with target --wasm32-unknown-unknown and then link 
>>>>>> using 
>>>>>> emscripten? The main problem with RUST is that it even can't compile 
>>>>>> with 
>>>>>> --wasm32-unknown-emscipten (because of lib dependencies that not support 
>>>>>> emscripten)
>>>>>>
>>>>>> чт, 13 янв. 2022 г. в 16:46, Floh <[email protected]>:
>>>>>>
>>>>>>> That's a very useful gist, Alon! I think that blog post would be 
>>>>>>> much appreciated by a lot of people who like to tinker with other 
>>>>>>> languages 
>>>>>>> :)
>>>>>>>
>>>>>>> On Wednesday, 12 January 2022 at 19:32:04 UTC+1 [email protected] 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Sat, Dec 25, 2021 at 6:02 AM Floh <[email protected]> wrote:
>>>>>>>>
>>>>>>>>> Ah, language and toolchain interoperability, one of my favourite 
>>>>>>>>> topics ;)
>>>>>>>>>
>>>>>>>>> Zig has nearly the same problems as Rust: it allows to compile to 
>>>>>>>>> WASM, it has both a WASI and Emscripten target, with the WASI target 
>>>>>>>>> working out of the box, but I gave up on the Emscripten target 
>>>>>>>>> because I 
>>>>>>>>> just couldn't get it to work.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I wrote up a demo of Zig + Emscripten here:
>>>>>>>>
>>>>>>>> https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3
>>>>>>>>
>>>>>>>> That uses GLES3 and Asyncify from Emscripten, so it's a small 
>>>>>>>> program but it uses interesting features.
>>>>>>>>
>>>>>>>> The gist also shows using C in the same way, where Emscripten is 
>>>>>>>> just the linker, not the frontend.
>>>>>>>>
>>>>>>>> I've been meaning to do the same with Rust and write a blogpost 
>>>>>>>> about all 3 but haven't found the time...
>>>>>>>>
>>>>>>>> - Alon
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>>
>>>>>>>>> IMHO it would be great if the Javascript shims and interop could 
>>>>>>>>> be somehow split out of the Emscripten SDK into a separate, smaller 
>>>>>>>>> "webapi-wasm-tools" SDK which could be better integrated with other 
>>>>>>>>> language toolchains. The goal should be that other programming 
>>>>>>>>> languages 
>>>>>>>>> can benefit from the work that went into the Emscripten SDK to access 
>>>>>>>>> web 
>>>>>>>>> APIs like WebGL, WebGPU, WebAudio etc... up to "EM_JS()" 
>>>>>>>>> functionality, 
>>>>>>>>> instead of having to duplicate this work, or requiring a separate 
>>>>>>>>> installation of the whole Emscripten SDK.
>>>>>>>>>
>>>>>>>>> There's a very promising project 
>>>>>>>>> https://github.com/schellingb/wajic by Bernhard Schelling which 
>>>>>>>>> has the same goals and which was used to port Mattias Gustavsson's 
>>>>>>>>> DOS-like 
>>>>>>>>> library to the web: https://mattiasgustavsson.com/wasm/
>>>>>>>>>
>>>>>>>>> Anyway... just my 2 cents :)
>>>>>>>>> -Floh.
>>>>>>>>> On Friday, 24 December 2021 at 15:16:23 UTC+1 caiiiycuk wrote:
>>>>>>>>>
>>>>>>>>>> Hi! Just want to share my experiment with using Rust and 
>>>>>>>>>> WebAssembly. I tried to port Vange-rs project (rust + wgpu) to 
>>>>>>>>>> browser. I 
>>>>>>>>>> used emscripten and unknown platforms. Both finally works, but have 
>>>>>>>>>> lot of 
>>>>>>>>>> obstacles. I am very sad about support level of emscripten in Rust, 
>>>>>>>>>> hope it 
>>>>>>>>>> will change at some day.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://caiiiycuk.medium.com/vange-rs-webassembly-in-rust-498e2f960a04
>>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>>
>>>>>>>> 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/99cc45ea-2307-4551-94b8-ecff9ad965a0n%40googlegroups.com
>>>>>>>>>  
>>>>>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/99cc45ea-2307-4551-94b8-ecff9ad965a0n%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/9e88b4b5-f110-4d90-a630-1c282a1febffn%40googlegroups.com
>>>>>>>  
>>>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/9e88b4b5-f110-4d90-a630-1c282a1febffn%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/CAKOm%3DVFgNcSPR-KFe35yg%2BU9NXFpG7U_Y5G0APbkZRf5UM2%2B8w%40mail.gmail.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVFgNcSPR-KFe35yg%2BU9NXFpG7U_Y5G0APbkZRf5UM2%2B8w%40mail.gmail.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/CAEX4NpRH1%2BxWEaTbjTvnk5kE5W4XwUjHefP8g1psk-pUvxVAtg%40mail.gmail.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRH1%2BxWEaTbjTvnk5kE5W4XwUjHefP8g1psk-pUvxVAtg%40mail.gmail.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/CAKOm%3DVEBtYrS_8fFYz9fmWoQNUwWqjXah%2B9f0cdZ4Jjd2%2BxVGQ%40mail.gmail.com
>>>>  
>>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVEBtYrS_8fFYz9fmWoQNUwWqjXah%2B9f0cdZ4Jjd2%2BxVGQ%40mail.gmail.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/CAEX4NpTmf%3DjhApcxA%3DoW6G_eOTDLLwyPyJbduWQnJqWBQj8EqA%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTmf%3DjhApcxA%3DoW6G_eOTDLLwyPyJbduWQnJqWBQj8EqA%40mail.gmail.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/CAKOm%3DVEOxJmiieN552iJW2M7SQK9kOoQTu8--iVNQFmB8rCz_w%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVEOxJmiieN552iJW2M7SQK9kOoQTu8--iVNQFmB8rCz_w%40mail.gmail.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/3b1ec71f-be17-4c3e-b74a-69a7ba867e42n%40googlegroups.com.

Reply via email to