Request: Linux support

[Adash-nitro]

I've been trying the past few days to use MuPDF.NET in a dockerized Linux environment without luck.
same story on WSL2 or an arm-based MAC

I learned the hard way that despite the base C MuPDF being fully capable of running on Linux (even ARM based), MuPDF.NET doesn't support it officially out of the box. There isn't any official information about it either.

Please add it, test it, make it officially support Linux.

This is a huge downside, a deal braker, of this library in a world where everybody on the cloud is shifting fully to Linux or requires the multi-platform nature .NET.

Exception for background:

System.TypeInitializationException: The type initializer for 'mupdf.mupdfPINVOKE' threw an exception.
  ---> System.TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
  ---> System.DllNotFoundException: Unable to load shared library 'mupdfcsharp.dll' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable: 
 /app/runtimes/linux-x64/native/mupdfcsharp.dll.so: cannot open shared object file: No such file or directory
 /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/mupdfcsharp.dll.so: cannot open shared object file: No such file or directory
 /app/mupdfcsharp.dll.so: cannot open shared object file: No such file or directory
 /app/runtimes/linux-x64/native/libmupdfcsharp.dll.so: cannot open shared object file: No such file or directory
 /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/libmupdfcsharp.dll.so: cannot open shared object file: No such file or directory
 /app/libmupdfcsharp.dll.so: cannot open shared object file: No such file or directory
 /app/runtimes/linux-x64/native/mupdfcsharp.dll: cannot open shared object file: No such file or directory
 /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/mupdfcsharp.dll: cannot open shared object file: No such file or directory
 /app/mupdfcsharp.dll: cannot open shared object file: No such file or directory
 /app/runtimes/linux-x64/native/libmupdfcsharp.dll: cannot open shared object file: No such file or directory
 /usr/share/dotnet/shared/Microsoft.NETCore.App/8.0.11/libmupdfcsharp.dll: cannot open shared object file: No such file or directory
 /app/libmupdfcsharp.dll: cannot open shared object file: No such file or directory

[Adash-nitro]

Hi, I was tracking the linked PR #157 with high hopes, now I see it's draft and stalled, any updates or some roadmap for this?

[jamie-lemon]

@Adash-nitro Thanks, we are actually still looking at the PR and working out the best approach for the repo for local development as well as being able to publish a cross-platform solution to NuGet. This is why it is in Draft, but in fact we are still looking at it and the best way forward.
In the meantime you can check out the NuGet package from the author of #157 here: https://www.nuget.org/packages/mupdf.net-x64-rn
This is a temporary solution until we have things officially running the way we want with our repo ( and our own internal publishing process to NuGet). Rest assured we will get it done and I hope the temporary NuGet package works for you in the meantime.

[Adash-nitro]

@jamie-lemon Checking in every few days, found out the 3.2.0, works as expected for my current use case!
more to come
I had issues on the metadata with that x64-rn package not catching exceptions under Linux terminate called after throwing an instance of 'mupdf::FzErrorGeneric' (seems you too, for whatever reason, I hope other exceptions will be properly handled, time will show)

[jamie-lemon]

@Adash-nitro Okay - great news and glad it works for you! Would you mind creating an Issue for this to help us track it.? (@robinwatts @MaksymTkachuk)

[Adash-nitro]

@jamie-lemon with that NuGet package from the author of #157 https://www.nuget.org/packages/mupdf.net-x64-rn I had the issue, not with the current 3,2,0 as you guarded the part of code that was failing for me with if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))

On windows it was correctly "catching the exception" for not found keys and setting the value to "none" while on Linux I was getting mupdf::FzErrorGeneric with message what(): code=1: key not found: info:Title (it was completely halting the execution of my unit tests)
The test was run with a document not having this field in the metadata of course.

[jamie-lemon]

@Adash-nitro Got it - I thought our version was throwing the exception as well - seems not and we had a guard in place - thanks for the confirmation.