Re: [Mono-dev] Multiplatform support with P/Invoke

[Jason Curl]

On 2016-01-01 13:17, Miguel de Icaza wrote:
Re-reading your original question makes me wonder if you really need 
something as heavy handed as the approach on Mono.Posix.


Specifically I will port my .NET implementation 
http://serialportstream.codeplex.com 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).


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.


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.



Then the C glue maps between those two.

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.


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.


Miguel


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.


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


Do you have time to highlight how the MapAttribute works in Mono.Posix?

Thankyou for your support,
Jason.


On Thu, Dec 31, 2015 at 8:15 PM, Jason Curl > wrote:


Thank you Mr. Icaza.

Is there more information on what uses the MapAttribute than
what's in Syscall.cs? Even though it's internal and I won't use
it, I'd like to understand how you solve the problem of ABI
compatibility.

I'd like to set up a solution where copying the files from one
architecture to another simply works (assuming all dependencies
from the runtime are present), and the runtime/mylib chooses the
most appropriate native library (based on OSVersion and
Syscall.uname) for all supported platforms. Something like:
* MyLib.dll (assembly)
* MyNativeLib.Linux.x86.so 
* MyNativeLib.Linux.x64.so 
* MyNativeLib.FreeBSD.x86.so 
* MyNativeLib.Darwin.x86.so 
* MyNativeLib.Win.x86.dll (windows native)
* MyNativeLib.Win.x64.dll (windows native)
* MyNativeLib.[dll|so] (backup for local builds)

Your solution (Mono.Unix.Native) looks different, more compact,
but I'm not sure if/how it supports side-by-side. My solution
requires a lot of work, duplicate code with small changes in
defining the structs/DllImports with different offsets and library
names.

I've yet to look into the Dll mapping mechanism of Mono if that's
also suitable.

Thank you very much and for giving me the opportunity to use Mono.

Regards,
Jason.



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Multiplatform support with P/Invoke

[Miguel de Icaza]

Re-reading your original question makes me wonder if you really need
something as heavy handed as the approach on Mono.Posix.

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.

Then the C glue maps between those two.

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.

Miguel

On Thu, Dec 31, 2015 at 8:15 PM, Jason Curl  wrote:

> Thank you Mr. Icaza.
>
> Is there more information on what uses the MapAttribute than what's in
> Syscall.cs? Even though it's internal and I won't use it, I'd like to
> understand how you solve the problem of ABI compatibility.
>
> I'd like to set up a solution where copying the files from one
> architecture to another simply works (assuming all dependencies from the
> runtime are present), and the runtime/mylib chooses the most appropriate
> native library (based on OSVersion and Syscall.uname) for all supported
> platforms. Something like:
> * MyLib.dll (assembly)
> * MyNativeLib.Linux.x86.so
> * MyNativeLib.Linux.x64.so
> * MyNativeLib.FreeBSD.x86.so
> * MyNativeLib.Darwin.x86.so
> * MyNativeLib.Win.x86.dll (windows native)
> * MyNativeLib.Win.x64.dll (windows native)
> * MyNativeLib.[dll|so] (backup for local builds)
>
> Your solution (Mono.Unix.Native) looks different, more compact, but I'm
> not sure if/how it supports side-by-side. My solution requires a lot of
> work, duplicate code with small changes in defining the structs/DllImports
> with different offsets and library names.
>
> I've yet to look into the Dll mapping mechanism of Mono if that's also
> suitable.
>
> Thank you very much and for giving me the opportunity to use Mono.
>
> Regards,
> Jason.
>
>
> On 2015-12-31 02:04, Miguel de Icaza wrote:
>
> For something like libc, you can use an approach similar to what
> Mono.Posix does, where an intermediate C glue file acts as a bridge between
> the API differences.
>
> See the P/Invokes for the Mono.Posix assembly, and its supporting glue
> code in mono/support/
>
> On Wed, Dec 30, 2015 at 5:58 AM, Jason Curl  wrote:
>
>> Hello,
>>
>> I'm investigating the best way on how to support multiplatform software
>> especially when using P/Invokes, but have not found any reasonable advice
>> on the Wiki.
>>
>> Can someone point to me on how to handle different architectures,
>> especially when the underlying libc might use different structures or API
>> signatures?
>>
>> Thanks,
>> Jason.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Multiplatform support with P/Invoke

[Jason Curl]

Thank you Mr. Icaza.

Is there more information on what uses the MapAttribute than what's in 
Syscall.cs? Even though it's internal and I won't use it, I'd like to 
understand how you solve the problem of ABI compatibility.


I'd like to set up a solution where copying the files from one 
architecture to another simply works (assuming all dependencies from the 
runtime are present), and the runtime/mylib chooses the most appropriate 
native library (based on OSVersion and Syscall.uname) for all supported 
platforms. Something like:

* MyLib.dll (assembly)
* MyNativeLib.Linux.x86.so
* MyNativeLib.Linux.x64.so
* MyNativeLib.FreeBSD.x86.so
* MyNativeLib.Darwin.x86.so
* MyNativeLib.Win.x86.dll (windows native)
* MyNativeLib.Win.x64.dll (windows native)
* MyNativeLib.[dll|so] (backup for local builds)

Your solution (Mono.Unix.Native) looks different, more compact, but I'm 
not sure if/how it supports side-by-side. My solution requires a lot of 
work, duplicate code with small changes in defining the 
structs/DllImports with different offsets and library names.


I've yet to look into the Dll mapping mechanism of Mono if that's also 
suitable.


Thank you very much and for giving me the opportunity to use Mono.

Regards,
Jason.

On 2015-12-31 02:04, Miguel de Icaza wrote:
For something like libc, you can use an approach similar to what 
Mono.Posix does, where an intermediate C glue file acts as a bridge 
between the API differences.


See the P/Invokes for the Mono.Posix assembly, and its supporting glue 
code in mono/support/


On Wed, Dec 30, 2015 at 5:58 AM, Jason Curl > wrote:


Hello,

I'm investigating the best way on how to support multiplatform
software especially when using P/Invokes, but have not found any
reasonable advice on the Wiki.

Can someone point to me on how to handle different architectures,
especially when the underlying libc might use different structures
or API signatures?

Thanks,
Jason.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com

http://lists.ximian.com/mailman/listinfo/mono-devel-list




___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list