Closed mHooshdar closed 2 months ago
Since this project is just a wrapper around the native library, my guess is that it fails to load the native library. Try to install it directly and see if there's a different binary for M1 than what's in this solution.
I have a M1 laptop and I was testing this the other day. Command line wkhtmltopdf works fine. I tried to copy the libwkhtmltox.dylib that came with the binary to the nuget package's runtimes directory but it didn't seem to work.
Should it work without changes to ModuleFactory
? The error originates from there but I didn't have time to investigate further then. Do we need a new module (akin to WkHtmlModuleLinux64) with correct DLLNAME
?
@pasih In theory the .NET runtime should use the correct subfolder to get the native library. Is the dylib file the same for M1 as for regular Macs, or do they have a specific M1 (it's ARM isn't it?) file?
I installed it from brew but I presume it's different (ARM). What I tried was copying the .dylib files (libwkhtmltox.0.12.6.dylib libwkhtmltox.0.12.dylib, libwkhtmltox.0.dylib and libwkhtmltox.dylib - most of them are just symlinks though) from /usr/local/lib to my ~/.nuget/packages/haukcode.wkhtmltopdfdotnet/1.5.72/runtimes/osx-arm64/native/ folder. Once the dotnet project loads, those are copied to bin/Debug/net6.0/runtimes/osx-arm64/native/.
I think these locations are correct but I haven't really had to deal with loading libraries in nuget packages so I could be mistaken.
I have added Linux ARM64 support now, but from what I can find on the WkHtmlToPdf parent page, it doesn't seem like they have builds for OSX ARM64 (M1) to run this wrapper in .NET for ARM64. It works in Docker on the M1 using ARM64 since I've just added the native library for that. And I can run it directly on the Mac but in X64 mode (emulated). It is my understanding that we need native ARM64 OSX package of wkhtmltopdf (parent project) to fully/natively support this.
I'm running into issues getting this working on M2 processor. Is there a resolution to this issue?
Edited to say: I have been able to install wkhtmltopdf with brew running natively. And been able to call the binary natively in terminal. I will be deploying to AppService with a Windows host, so no forseen issue there, but I would love to be able to develop against this on my mac. Can I point the package to the installed binary and have it use that when doing my development?
Unfortunately it appears that the binary installed with brew is x86_64, not arm 64 native.
% file /usr/local/bin/wkhtmltopdf
/usr/local/bin/wkhtmltopdf: Mach-O 64-bit executable x86_64
I see, so it's using emulation. But then that should work under the .NET project as well, maybe it's just not probing the correct location?
Thanks, I'll look into placing it in a different location.
I never got this working @HakanL Were you able to?
@TimZander I assume it's an issue with the native library not having native support for the M1. I don't think there's much we can do, short of building the wkthmltopdf binaries for the platform. When loading the native library from .NET there aren't a lot of controls, we're basically just saying we need this DLL: https://github.com/HakanL/WkHtmlToPdf-DotNet/blob/master/src/WkHtmlToPdf-DotNet/WkHtmlModule.cs#L83 Perhaps the .NET loader detects that it's Arm64 and looks for that type of binary. I remember looking at SqLite when I forked this project to see how they embed the native binaries, maybe you can get some ideas from there and see if they have a solution/workaround. I closed the issue because I think it's an issue outside the project, but feel free to re-open if you find any more. I'm happy to accept a fix/PR, I just don't know if it's anything in this project that can be fixed.
@TimZander I played with this a little more on my M1. I was doing my tests with .NET8, but I think the same will apply to 6 and 7 (any that supports ARM64). If I install the .NET SDK 8 for x64 and run it via that version of dotnet
then it runs fine (/usr/local/share/dotnet/x64/dotnet run
). If I run it via the ARM64 dotnet
(on the path) then it can't find the native library (because one doesn't exist). If I publish the TestConsoleApp targeting osx-x64
then it works fine, osx-arm64
doesn't. I don't think there's really anything wrong here, as much as I'd love for a native arm64 build to be available of the wkthmltox native library, until one is available we won't be able to run this natively in the arm64 space. If the caller (.net) is arm64 then I doubt there is a way for it to load a x64 native library via Rosetta, maybe there is a way, this is outside my knowledge.
Hi, I tried this package on MacBook with M1 processor and I got this error:
I tried it on another mac and it is been worked. I think that this package does not M1 processor Can you help me to solve this?