For something like this, instead of trying to do a high fidelity mapping of the low level APIs that you would call from C# and then do the abstraction work from C#, I would instead do the heavy lifting in C, provide the abstraction there and surface a simple API to C# which you invoke there.<div><br></div><div>Miguel<span></span><br><br>On Friday, January 1, 2016, Jason Curl <<a href="mailto:jcurlnews@arcor.de">jcurlnews@arcor.de</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 2016-01-01 13:17, Miguel de Icaza wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Re-reading your original question makes me wonder if you really need something as heavy handed as the approach on Mono.Posix.<br>
</blockquote>
<br>
Specifically I will port my .NET implementation <a href="http://serialportstream.codeplex.com" target="_blank">http://serialportstream.codeplex.com</a> to Mono on Linux, but why stop there? I would further consider BSD socket networking code which is much more complicated (especially obtaining interface names).<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The challenge that Mono.Posix faces is that the structures exposed in each Unix is slightly different (different location for fields, different data types for fields), so Mono.Posix resorts to defining its own interface, say instead of using "struct stat" and trying to have one universal implementation that works across many different Unix systems - it instead defines a "struct MyStat" which has well known fields at well known locations with well known sizes.<br>
<br>
</blockquote>
I've experience in writing portable code with the help of Autotools on Solaris, FreeBSD, Linux, Cygwin and QNX, all of which have their own quirks as you've needed to solve with Mono.Posix.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then the C glue maps between those two.<br>
<br>
But in your case, it is not clear if you are trying to bind libc and their structures, or trying to bind your own C library that already has a stable ABI.  If you are coping with the latter, you do not need a setup as tedious as the one that Mono.Posix does, you merely need to ship your native library for each platform you intend to support and your C# code that calls into it.<br>
</blockquote>
<br>
I've not started the port of my project to Unix and so have no library already. I will write one though, as it seems the solution that Mono.Posix has taken. It also appears the only /portable/ way that I can take without having to make assumptions about structure layouts.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Miguel<br>
</blockquote>
<br>
I took a further look at DllMaps, and while I haven't started/tested yet, I believe this can simplify effort by allowing me to having one native lib per architecture and a single .NET class that "standardizes" the interfaces I need.<br>
<br>
I'm still researching the best way. Right now, I'm planning on having a Cmake/Autotools project to build my library for the platform, use DllMaps to let the Mono runtime pick the appropriate native library when running if OSVersion is Unix (etc.)<br>
<br>
Do you have time to highlight how the MapAttribute works in Mono.Posix?<br>
<br>
Thankyou for your support,<br>
Jason.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Thu, Dec 31, 2015 at 8:15 PM, Jason Curl <<a>jcurlnews@arcor.de</a> <mailto:<a>jcurlnews@arcor.de</a>>> wrote:<br>
<br>
    Thank you Mr. Icaza.<br>
<br>
    Is there more information on what uses the MapAttribute than<br>
    what's in Syscall.cs? Even though it's internal and I won't use<br>
    it, I'd like to understand how you solve the problem of ABI<br>
    compatibility.<br>
<br>
    I'd like to set up a solution where copying the files from one<br>
    architecture to another simply works (assuming all dependencies<br>
    from the runtime are present), and the runtime/mylib chooses the<br>
    most appropriate native library (based on OSVersion and<br>
    Syscall.uname) for all supported platforms. Something like:<br>
    * MyLib.dll (assembly)<br>
    * <a href="http://MyNativeLib.Linux.x86.so" target="_blank">MyNativeLib.Linux.x86.so</a> <<a href="http://MyNativeLib.Linux.x86.so" target="_blank">http://MyNativeLib.Linux.x86.so</a>><br>
    * <a href="http://MyNativeLib.Linux.x64.so" target="_blank">MyNativeLib.Linux.x64.so</a> <<a href="http://MyNativeLib.Linux.x64.so" target="_blank">http://MyNativeLib.Linux.x64.so</a>><br>
    * <a href="http://MyNativeLib.FreeBSD.x86.so" target="_blank">MyNativeLib.FreeBSD.x86.so</a> <<a href="http://MyNativeLib.FreeBSD.x86.so" target="_blank">http://MyNativeLib.FreeBSD.x86.so</a>><br>
    * <a href="http://MyNativeLib.Darwin.x86.so" target="_blank">MyNativeLib.Darwin.x86.so</a> <<a href="http://MyNativeLib.Darwin.x86.so" target="_blank">http://MyNativeLib.Darwin.x86.so</a>><br>
    * MyNativeLib.Win.x86.dll (windows native)<br>
    * MyNativeLib.Win.x64.dll (windows native)<br>
    * MyNativeLib.[dll|so] (backup for local builds)<br>
<br>
    Your solution (Mono.Unix.Native) looks different, more compact,<br>
    but I'm not sure if/how it supports side-by-side. My solution<br>
    requires a lot of work, duplicate code with small changes in<br>
    defining the structs/DllImports with different offsets and library<br>
    names.<br>
<br>
    I've yet to look into the Dll mapping mechanism of Mono if that's<br>
    also suitable.<br>
<br>
    Thank you very much and for giving me the opportunity to use Mono.<br>
<br>
    Regards,<br>
    Jason.<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
Mono-devel-list mailing list<br>
<a>Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</blockquote></div>