LibraryExtractor fails on Raspbian 10.

[jpfdf]

I'm having this error log when trying to get the plc tag on Raspbian 10.
The same app compiled for windows does not have this problem.

2020-11-26 14:43:56.994 -03:00 [ERR] System.TypeLoadException: This platform is not supported, could not load appropriate unmanaged library
   at libplctag.NativeImport.LibraryExtractor.GetResourceName()
   at libplctag.NativeImport.LibraryExtractor.ExtractAppropriateLibrary(String folder)
   at libplctag.NativeImport.LibraryExtractor.Init(Boolean forceExtract)
   at libplctag.NativeImport.plctag.ExtractLibraryIfRequired()
   at libplctag.Tag.Initialize()
   at libplctag.Tag`2.Read()

On the original libplctag documentation says that RaspberryPi is supported. Do it mean that libplctag.NET supports it too?
would plctag.ForceExtractLibrary = false; solve this issue?

The Os details are the following

• OS: Raspbian GNU/Linux 10 (buster)
• Kernel: Linux 5.4.51-v7+
• Architecture: arm

The NuGet package is

• libplctag 1.0.0
  thanks.

[timyhac]

Hi there - if you can compile libplctag core for ARM then yes you would need to use plctag.ForceExtractLibrary = false; in order to make use of your own runtime.

libplctag core currently isn't doing any builds for ARM architecture but @kyle-github do you know if this is possible/plausible?

[kyle-github]

Hi @timyhac, @jpfdf, yes, the core C library builds on Arm. I have been cross compiling it for Android recently and that builds Arm executables. It works fine during that process. However, that process of cross-compiling is built into Android Studio and is fairly opaque to me.

The main artifacts do not include Arm today. Unfortunately, GitHub Actions (GitHub's CI system) does not provide Arm-based executors. It may be possible to cross-compile, as is done automatically for Android, but I cannot promise anything. I have done cross compilation in the past (a loooonnnngg time ago) and it was a complete pain. Hopefully the state of the art has advanced since then.

The easiest thing for now would be to build it on an RPi directly, and then use that as @timyhac outlines above.

RPi Raspian is a derivative of Debian, so the instructions in the distribution BUILD.md file should be fine.

As interest is increasing for embedded systems, I think my focus is going to shift toward those for a while, so I will look into what it would take to generate binaries for other processors in the main build process.

[timyhac]

In terms of what the .NET wrapper needs to do, I guess the error message could be a little bit more helpful, and indicating this as a use-case could be added to https://github.com/libplctag/libplctag.NET#libplctagnativeimport.

I think I'd prefer that, when there is no built-in runtime, the wrapper does not try to provide different help depending on whether libplctag supports the system or not, because that could get very verbose very quickly, and would add a maintenance requirement when libplctag core enables a new platform.

[kyle-github]

There probably are not many (any?) platforms where the .Net wrapper works but the core library does not build.

That said, binaries for RPi is probably a good thing to have more or less out of the box for the core library. That way you can just include it into the wrapper and everything will just work.

I should be able to make Windows IoT (Arm) builds too. There are instructions on how to do that. Mostly what it takes is different command line arguments on Windows to tell Visual Studio to cross-compile. Those work on Windows 10 IoT for RPi.

[timyhac]

@kyle-github - yes I too would think that anywhere .NET CLR can run, the core library can - I was just reading about MIPS support (or lack of) for .NET CLR which I see libplctag supports.

I agree that ARM builds would be useful - I assume that raspbian is related to debian, so the reported OS would be linux, which means we can detect it in the wrapper.

[timyhac]

@jpfdf - I hope this response resolves your issue, will close the ticket.

[kyle-github]

Yep, Raspian is a derivative of Debian. Fairly close IIRC. I never did much with my RPi, so I am not sure just how close it is.