After deinstalling Curl and libcurl from Entware (can’t remove it from Optware as git requires it) it still the same.
And as a simpleton, I also tried adding a symlink in lib64, but that also didn’t help.
Run sonarr with MONO_LOG_LEVEL=debug MONO_LOG_MASK=dll,cfg mono --debug /../../NzbDrone.exe in the console, preferably in something with a reasonably large buffer so you can scroll back, or log to file.
Here you go:
Also, I cross-compiled curl into the package. The error changes to Curl Error SslCaCert for Url. That’s probably because we (currently) don’t specify a CA bundle with OpenSSL. That’s something I’ve been considering for other reasons, but hadn’t done yet.
I’ll look into that in a bit more detail, maybe next week.
I actually expected it to try a couple of different paths.
Well, to be clear, the package uses this to start Sonarr: https://github.com/SynoCommunity/spksrc/blob/master/spk/sonarr/src/dsm-control.sh#L17
So I ended up with this: env PATH=/usr/local/mono/bin:$PATH LD_LIBRARY_PATH=/usr/local/nzbdrone/lib MONO_LOG_LEVEL=debug MONO_LOG_MASK=dll,cfg /usr/local/mono/bin/mono --debug /usr/local/nzbdrone/share/NzbD rone/NzbDrone.exe
After cross-compiling libcurl into the package, it ends up in /usr/local/nzbdrone/lib, and that’s searched too…it doesn’t show up here though (removed it to test properly)
I tried making a symlink in /volume1/@appstore/nzbdrone/share/NzbDrone/ to /lib.
That didn’t seem to help.
Ok, this is what I was looking for. I created a symlink to /lib/libcurl.so.4.3.0, and ran the command again, with the following result:
Mono: DllImport error loading library '/volume1/@appstore/nzbdrone/share/NzbDrone/libcurl.so.4': '/volume1/@appstore/nzbdrone/share/NzbDrone/libcurl.so.4: wrong ELF class: ELFCLASS32'.
Fyi, Synology uses a lot of 32b libs on the 64b-based models, and not a lot of 64b libs are available.
Usually, not a problem. However, we do compile Sonarr with a 64b toolchain…
With the 64b libcurl added in, the ELF class error disappears, and the CA-cert error comes back. So that will probably be the direction to go.
that’s actually interesting coz normally we run sonarr 32bit. Edit: … on windows.
Anyway, if you or maximus can fix the x64 package I’ll change the dllmap to libcurl.so.4 and get that to our develop branch.
Sure, thanks.
I’ll see if I can tell OpenSSL to work nicely with a cert bundle, that should get that curl error out of the way. I’ll report back when done. Hopefully over the weekend, but no ETA: It’ll affect multiple packages on our side, so it needs some testing.
/edit: btw, Seeing as I have only a limited idea of how Sonarr and Mono interact, wouldn’t it be more correct to say that we compile Mono with a 64b toolchain, and that causes the ELF class issue?
From my perspective there is no hurry. I added libcurl only as fallback for those situations where a site doesn’t support older cipher suites and the site requires https (or the user somehow absolutely wants it). In all other cases libcurl isn’t even used, even with https enabled. Most sites have liberal cipher requirements, but the biggest culprit is Cloudflare free service, which requires the elliptic curve ciphers.
In case of rarbg it’s easy, coz they support http: as well. So, no hurry.
As for the 64b, it runs as 64b on my ubuntu server as well, but that has all the required native libs as separate packages.
The most tricky OS is OSX coz we have to supply some libraries (mediainfo,sqlite) ourselves, which are 32b, so running sonarr on OSX requires 32b mono.
You probably could compile mono 32b for syno, but that could cause issues when other apps expect 64b.
Edit: added GH issue for tracking:
Thanks guys, would have never been able to figure this out with my magical copy/paste and extensive trial and error skillset.
I Have lib curl and it still does not work, my server is in germany.
Just to update, downloading the new Synology package, and then altering “/var/packages/nzbdrone/target/share/NzbDrone/CurlSharp.dll.config” to “dllmap os=“linux” dll=“libcurl.dll” target="libcurl.so.4” does the trick.
To any Sonarr devs. Can ‘NzbDrone/CurlSharp.dll.config’ be modified to have freebsd use libcurl.so.4
That is what is available according to https://github.com/freebsd/freebsd-ports/blob/master/ftp/curl/pkg-plist
Once that is modified, and Sonarr has a new release, I’ll update the FreeNAS plugin to include curl.
Thanks!
That’s already available in the develop branch.
You could symlink the current master version number to the new libcurl. That will make it work for both scenarios.
just to clarify, what’s available, the curlsharp.dll.config? if so, I understand that.
as far as your symlinking suggestion, are you referring to symlinking libcurl.so.4 to libcurl.so.3?
Yes, master is still set to libcurl.so.3, develop branch is set to libcurl.so.4
No, the other way around. If you symlink libcurl.so.3 to libcurl.so.4 both the master and develop will effectively utilize libcurl.so.4.
My Synology is effectively utilizing 4.3.0, as 4 is requested in config file, and 4 is being symlinked to 4.3.0 (libcurl.so.4 -> libcurl.so.4.3.0)
great! thanks for the explanation.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.