Plan for unix support

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.

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

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

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

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.

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

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

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

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

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

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)

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.

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

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.

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).

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

I have seen your fix in the commit 0afdcdd

Looks good to me :)

Thanks!!!

Navigation Menu

Repository navigation

Plan for unix support #2

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Plan for unix support #2

Description

Activity

OpenByteDev commented on Mar 10, 2021

david-bouyssie commented on Mar 10, 2021

OpenByteDev commented on Mar 10, 2021

david-bouyssie commented on Mar 10, 2021

OpenByteDev commented on Mar 10, 2021

OpenByteDev commented on Mar 24, 2021

david-bouyssie commented on Mar 25, 2021

OpenByteDev commented on Mar 25, 2021

OpenByteDev commented on Apr 11, 2021

david-bouyssie commented on Apr 12, 2021

david-bouyssie commented on Apr 12, 2021

OpenByteDev commented on Apr 12, 2021

david-bouyssie commented on Apr 12, 2021

david-bouyssie commented on Apr 12, 2021

OpenByteDev commented on Apr 12, 2021

david-bouyssie commented on Apr 13, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions