libcurl linked by SOUL_PatchLoader.so incompatible with default libcurl on Arch, Debian, Ubuntu?

[DocSunset]

Running the SOULPatchHostDemo, I always get the message "Failed to correctly load the patch DLL." I am compiling and running on Arch Linux 5.7.7, so I had to hard code the path to the shared library, but I'm reasonably sure this is not the source of the issue.

I wrote a minimal program to reproduce the behavior I'm seeing, which looks like this:

#include <path/to/soul_patch.h>

int main ()
{
    const char * soul_patch_library_path = "/path/to/libSOUL_PatchLoader.so";
    auto lib = soul::patch::SOULPatchLibrary(soul_patch_library_path);
    if (!lib.loadedSuccessfully())
    {
        return 1;
    }
    return 0;
}

I compile with g++ test.cpp -ldl, and running ./a.out; echo $? always prints 1.

Compiling the same program (after changing libSOUL_PatchLoader.so to SOUL_PatchLoader.dylib) on macOS 10.14 with clang test.cpp -lc++ works fine, and ./a.out; echo $? prints 0.

I am using the header and binary library from the latest release at the time of writing (0.9.33).

[DocSunset]

The following similar program produces a more informative error:

#include <soul/API/soul_patch/API/soul_patch.h>
#include <iostream>

int main ()
{
    const char * soul_patch_library_path = "/usr/lib/libSOUL_PatchLoader.so";
    auto lib = dlopen(soul_patch_library_path, RTLD_LOCAL | RTLD_NOW);
    if (lib == nullptr)
    {
        std::cerr << dlerror() << "\n";
        return 1;
    }
    return 0;
}

When run I get the following error:

$ g++ test.cpp -ldl && ./a.out; echo $?
/usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by /usr/lib/libSOUL_PatchLoader.so)
1

Perhaps the version of libcurl shipped by my distribution differs from the one expected by libSOUL_PatchLoader.so?

[DocSunset]

An easier way to reproduce the above error (version 'CURL_OPENSSL_3' not found) seems to be simply running ldd /path/to/libSOUL_PatchLoader.so. The first line of output is identical to the message produced by dlerror().

nm -D /usr/lib/libcurl.so shows that there is an symbol "CURL_OPENSSL_4" on my distribution.

Spinning up a fresh Debian vm and running nm -D .../libcurl.so.4 on the version of libcurl that comes as the default dependency library for apt-get installing curl shows the same symbol, CURL_OPENSSL_4. I get the same error (version not found) when running ldd libSOUL_PatchLoader.so in this fresh Debian vm.

A bit of Googling around for CURL_OPENSSL_3 yields a few Github issues on various (unrelated) projects where people have reported an error similar to the one I get from dlerror, usually solved by either downgrading their system installation of libcurl or by upgrading the version used on the project.

All of this leads me to believe that the issue I'm seeing is likely to do with the version of libcurl linked to by the SOUL_PatchLoader.so library. Is it possible that you guys linked to an older version when building the Linux version of the library?

It seems a bit strange, since there doesn't even seem to be an OpenSSL flavoured libcurl3 package available for Debian, nor Ubuntu, which I would assume you guys would be targeting for support, even if you aren't explicitly targeting Arch.

[julianstorer]

Thanks for doing some digging there and giving us a detailed report!

We're relying on JUCE internally to load CURL, and it should be trying to dynamically find the curl DLL like this: https://github.com/juce-framework/JUCE/blob/a30f7357863a7d480a771e069abf56909cdf0e13/modules/juce_core/native/juce_curl_Network.cpp#L86

..so I'm a bit puzzled about why it would fail to find it on your machine, and not really sure what we could change to improve this..

[julianstorer]

OK - we figured this out!

It was just a silly mistake - we were missing a JUCE flag in our DLL build - I'm going to close this issue now as it should be fixed in our next build, but please re-open if you still have any problems!

[DocSunset]

Great! Looking forward to the next release.