Exception thrown on Linux

[superstator]

When loading an image on Linux (Ubuntu 16.04) under .Net Core, I'm getting an exception:

Code: Select all

Unable to load DLL 'Magick.NET-Q8-x64.Native.dll': The specified module or one of its dependencies could not be found.\n (Exception from HRESULT: 0x8007007E)

I am using Q8-AnyCPU 7.3. I see there is a Magick.NET-Q8-x64.Native.dll.so packed in the Linux-x64 runtimes for the nupkg, but from the error message it seems like it is still looking for the Windows library. Possibly a bug, or am I missing something?

[superstator]

Continuing to poke at this, and it seems to all come down to DLL-hell (or, so-hell, I suppose). I have the Magick.NET.Native library loading, but the underlying ImageMagick libraries are still failing with 'ImageMagick.MagickMissingDelegateErrorException: no decode delegate for this image format' for all formats. To get that far required finding, building, and installing the right versions of ImageMagick and setting LD search paths. Only after working that all out myself, of course, I discovered https://github.com/dlemstra/Magick.NET/ ... latform.md, which explains just that. So, that's my fault for not digging further into the docs sooner.

I'd love to see this be easier and cleaner to work with. As an end-user, I'd like to be able to add a NuGet ref to a .NET Core project and know it will "just work" as much as possible, both for me and for my own downstream users. I'm happy to work on this and contribute some changes/code back to the project if the maintainers are open to it. dlemstra, do you have any strong opinions about how this stuff should work? Would you rather see ImageMagick binaries packed into the Magick.NET nupkg, or a statically linked Magick.NET.Native wrapper, or some third option?

[superstator]

I have a proof of concept static version of Magick.NET-Q8-x64.Native.dll.so working now on my system. In a nutshell, the Dockerfile for building the base ImageMagick library needed tweaking to let the format delegates build correctly, and then I was able to just add a flag to compile PIC (which really should be the default anyway), add some linker args, and we're off to the races. The final binary is bigger, of course, but it's still much smaller than the Windows runtime .dlls (about 6mb from 300k vs 13-15mb for Windows).

If need be we can keep a fork active and just use this internally, but I'd love to see about getting it folded back into the main project for other folks benefit.

[dlemstra]

I have thought about making the ImageMagick library static and decided to not do it because I thought that Linux users might prefer to build their own version. But having this as a static library would make it much easier for the users to use. And when someone wants to link other versions of the libraries they still can as long as we have a proper build script for this. I am deferentially open to making this change. Can you open a PR/issue on github and demonstrate what you have done?

[superstator]

I want to do a little more testing on my end first, but I'll send you a PR soon, hopefully this week.

[superstator]

Do you have any opinions about which format delegates and compression libraries to build in? I have it working with zlib, libjpeg-turbo, libtiff5, libpng16, and libwebp. Anything else you definitely do (or do not) want to see supported out of the box? LZMA, BZ2, etc?

I've also waffled a little about just how vanilla of a system to support. I think going all the way down to libstdc++ etc would be a little silly, but I also want to be as plug and play as possible to fit what I think most people expect from a managed code nuget package. For now I know it works on a vanilla copy of the microsoft/dotnet docker image, and I think that's a good benchmark unless you have opinions otherwise.