Mono/Linux Support

[hackathi]

Hey,

awesome work you put up here. I'm currently writing a cross-platform application using your framwork and tried to run it on mono/linux, which should'nt be a problem in general.

In particular, there are a few caveats at the moment:

• you need to use dllmap for libcapstone.dll --> libcapstone.so. Solution: just omit .dll in your DllImports. It will be handled automatically by the framework (.NET as well as mono).
• I can't find the source code of Gee.External.Capstone, so I can't compile it for *nix, and therefore, not run it.

If you could provide the sourcecode for the proxy library I will finish the porting.

[9ee1]

Hello:

Thanks for your feedback.

For the first point, you can use conditional compilation symbols to work around the name of the DLL you want to import against. I usually prefer that as opposed to omitting it to make it clear which DLL is being imported.

For the second point, you are right. I forgot to commit the source code for Gee.External.Capstone.Proxy. I will do that and update this issue. Sorry about that.

Would you mind requesting a pull request so that I can merge your changes? I had a plan to make the API cross platform but didn't get the time it would be awesome to merge your changes.

Thanks!

[9ee1]

Hey:

I just realized, stupidly, the Gee.External.Capstone.Proxy DLL is not part of the solution directory structure. To save you some time, because I am already late in replying to this issue, here is the code. It is a simple proxy, as the name suggests, to work around alignment issues with a structure that has a union. Compiling it on *NIX should be straight forward. Sorry again about the delay:

#include <capstone.h>

extern "C" {
    __declspec(dllexport) cs_arm* CapstoneArmDetail(cs_detail *detail) {
        return &detail->arm;
    }

    __declspec(dllexport) cs_arm64* CapstoneArm64Detail(cs_detail *detail) {
        return &detail->arm64;
    }

    __declspec(dllexport) cs_x86* CapstoneX86Detail(cs_detail *detail) {
        return &detail->x86;
    }
}

[hackathi]

Hey,

thanks for your reply. I will give it a shot. Regarding names in dllimport - the "official" guideline is just to don't use an extension at all (for Windows, this includes having no dot in your assembly name). I think we cannot get rid of in whatever way we choose because of the proxy dll name, so it isn't that important to me for the moment.

[9ee1]

Hello:

I am not familiar with the official Mono guidelines honestly. But again, I am pretty sure you can work around it by having conditional compilation symbols when defining the imports.

Good luck.

[hackathi]

Yeah, actually, mono itself does some magic. Using strace(1), I found out that it looks for libcapsone.so and libGee.External.Capstone.Proxy.so in the current directory, so if you're happy with that name, it can be kept this way. I personally dislike conditional compiling for DLLImport, because what's the point on having cross-platform binary compatibility if I need to compile it for different platforms like this. This would affect OSX too, because their library extension is .dylib.

So far, it seems to run fine in monodevelop, but crashes if I run my app directly from command line. I'm still investigating the cause.

Also, here's a makefile for the proxy library; it includes the c file ported to compile with linux. See this gist: https://gist.github.com/masterofjellyfish/5bc715c292a75e5eae3d

[9ee1]

Thanks for the GIST. I'll include it in the next release here.

I see your point on the conditional symbols. I am not married to the name of the library. It is just the convention I always use personally. If it will cause problems, I don't mind changing it to make it simple.

[a2intl]

@9ee1 , can you please incorporate the proxy.c and Makefile for libGee.External.Capstone.Proxy.so from the gist (corrected URL) into the sourcetree & build? I've submitted a PR to the reko project which uses Capstone.NET in order to get it building & passing unit tests on mono / monodevelop , and needed to build a libGee.External.Capstone.Proxy.dll.so linux library from the gist.