Plan for unix support

[david-bouyssie]

Do you have planned to add support for unix platforms?

According to this example it seems to be doable:
https://github.com/dotnet/samples/blob/main/core/hosting/HostWithHostFxr/src/NativeHost/nativehost.cpp

However I have noticed a distinction regarding strings which seem to be wide on windows (typedef wchar_t char_t) but not on unix (typedef char char_t).

Would be happy to contribute to this addition but help might be needed.

[OpenByteDev]

I plan to add unix support, but it is not high on my priority list as I dont personally use it.

[david-bouyssie]

Ok great, let me know if I can help on a PR.

[OpenByteDev]

If you want to implement it yourself I would be more than happy to merge a PR.

[david-bouyssie]

Well, if you give me a hint of what I should change first, I can work on it.
I have already identified the WideString vs CString difference, but I may have missed other points.

[OpenByteDev]

The difference in string types should be the only change required.

[OpenByteDev]

I created an initial version that supports os other than windows.
It builds, but there are some errors on the tests: https://github.com/OpenByteDev/netcorehost/runs/2180322999?check_suite_focus=true

[david-bouyssie]

Wow awesome, thank you for this effort!

It seems that you are linking C++ code with rust. So you have to include the C++ standard library.
Can you please try with "cargo:rustc-link-lib=dylib=stdc++"?

For reference: https://users.rust-lang.org/t/linking-c-on-rust-undefined-reference-to-operator-delete-void-and-gxx-personality-v0-libstdc-missing/49658

[OpenByteDev]

I already tried that yesterday, but the tests are still failing (now with less errors).
Interestingly they only seem to fail when run together...

[OpenByteDev]

To clarify:

• Building succeeds without error.
• When a specific test is run with cargo test --test [testname] (e.g. cargo test --test hello_world) every test succeeds.
• When all tests are run at once with cargo test linking fails with this error:

/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/iostream:74: undefined reference to `std::ios_base::Init::Init()'

The full error log is available here: https://github.com/OpenByteDev/netcorehost/runs/2192279154?check_suite_focus=true

[david-bouyssie]

This is weird, in this context some headers seem to be loaded from a non-existing directory:
/opt/rh/devtoolset-7/root/usr/

I can reproduce the issue on Ubuntu 18.04 (WSL)

[david-bouyssie]

In bindings\nethost.rs I added this:

#[link(name = "nethost", kind = "static")]
#[link(name = "stdc++", kind = "dylib")]
extern "C" {
    /// Get the path to the hostfxr library
...

And I removed from build.rs:

println!("cargo:rustc-link-lib=dylib=stdc++");
println!("cargo:rustc-link-lib=static=nethost");

This seems to work.

[OpenByteDev]

Nice!
Do you know why this works and my version did not?

[david-bouyssie]

No, sorry, I'm missing knowledge there. But maybe on the rust gitter you may have a chance to get some clues.
I'm not even sure if the proposed solution is the way to go.

[david-bouyssie]

BTW, I found this other interesting project:
https://github.com/AaronRobinsonMSFT/DNNE

It's also based on nethost and provides an utility to generate C source files to be linked against nethost (from exported functions with or without UnmanagedCallersOnly).

[OpenByteDev]

It seems that the link attribute does not work for windows? (at least in this situation; again linking errors)

[david-bouyssie]

I have seen your fix in the commit 0afdcdd

Looks good to me :)

Thanks!!!