Is curl required to make https calls on linux?

Linux
1

My network calls do not work on linux and I don’t want to use CURL. CURL isn’t installed on Ubuntu by default. Is there another way around it to make HTTPS calls. I thought JUCE does have it’s own implementation to make https calls?!

The same code works on Windows and macOS.

Any help welcome

In my case I want to make a POST call with a json body.

Example Code:

        juce::URL url(urlString);

        juce::String deviceName = juce::SystemStats::getComputerName();

        juce::DynamicObject* dyn_obj = new juce::DynamicObject;
        dyn_obj->setProperty ("ProductName", productName);
        dyn_obj->setProperty ("DeviceName", deviceName);
        url = url.withPOSTData (JSON::toString (juce::var (dyn_obj)));

        // Perform the POST request
        auto options = juce::URL::InputStreamOptions(juce::URL::ParameterHandling::inPostData)
                .withExtraHeaders("Content-Type: application/json")
                .withConnectionTimeoutMs(2000)
                .withHttpRequestCmd ("POST")
                .withStatusCode(&statusCode);

        std::unique_ptr<juce::InputStream> responseStream = url.createInputStream(options);
2

Seems that libcurl is required for https/ssl on Linux, so you might be out of luck until someone decides to replace CURL usage with something else …

From juce_core/juce_core.h:

/** Config: JUCE_USE_CURL
    Enables http/https support via libcurl (Linux only). Enabling this will add an additional
    run-time dynamic dependency to libcurl.

    If you disable this then https/ssl support will not be available on Linux.
*/
#ifndef JUCE_USE_CURL
 #define JUCE_USE_CURL 1
#endif
1 Like
3

Thanks for clarifying. Makes sense.

4

Hello

All the dependencies on LINUX are listed here :

And libCurl is in juce_core

1 Like
5

curl is optional. I was confused because of this post:

6

So, will you make curl a dependency for your Linux build, or are you going to come back to this problem later?

Its not like you can’t produce a .deb with the dependency enabled, right?

7

I don’t know much about linux. It’s a runtime dependency if I understand right. Users need to install curl manually to make the plugin load after this change. Or are there other solutions?

8

No, that’s not an option for me.

9

There is not a good way to solve this problem except to instruct your users to install it if they do not have it installed (unlikely on most distros) or to distribute a package (.deb, .rpm) that installs your plugin and its dependencies. It is possible to bundle multiple shared objects into a single plugin bundle and have the loader discover them, but this is not a good idea to use with a common dependency like libcurl.

Not sure why a .deb bundle isn’t an option. They’re very easy to create.

10

Yes, I see. I’ll write it into our readme file then. We don’t have an installer on Linux.

11

How do hosts handle that?
I would assume most of them also need https access, don’t they?

12

That’s also something I wondered. It looks like Bitwig and Reaper don’t need curl and bitwig shows notifications about new updates.

13

What is the issue with building and distributing a .deb with your plugin? This is kind of easy to do on Ubuntu …

The reason I ask is because I’m also interested in getting this automated, myself, so maybe its something we can work through …

14

I don’t want to invest more time into this at the moment. It’s goodwill that we make Linux versions of our products. It costs probably more than we earn.

I hoped this platform would rise in popularity with hosts like Bitwig and Reaper. But it feels like not much has changed in the last few years and there are unresolvable issues like file drag and drop that can’t be fixed for all DAWs. Please correct me if I’m wrong.

15

Chicken and egg problem … people are less prone to trying out Linux versions of products if the effort isn’t made to package them properly.

But, understandable that its a time resource issue.

In any case, I’m working on fully automated JUCE packaging for .deb and .rpm, just as I have done for .exe (Windows) and .pkg (MacOS) for our projects, so maybe this is something worth contributing back at some point …

2 Likes
16

Only the development header is required for the build.

I don’t think you would have this as a dependency for the installed package.

17

Hosts can be distributed as flatpak or snap bundles which contain their shared library dependencies. Alternatively you can ship a .deb/rpm bundle and let the distro package manager figure it out.

Bigwig is a JRE application so I assume it uses whatever TLS implementation comes from the standard library there or in one of its .jar libraries that are bundled with it.

Worst comes to worst, it’s not that hard to statically link libcurl. It’s a couple lines of configuration in your build.

1 Like
18

For a plugin I’d recommend to always try and statically link your dependencies.

19

Its an interesting dilemma for a plugin, to have to deal with network traffic like it were another stream …

For a plugin I’d recommend to always try and statically link your dependencies.

IMHO, this is potentially bad for the user, I would instead suggest that the plugin/library boundary on Linux exploit the situation a bit more broadly than the walled-gardens … inasmuch as its always better to use the libcurl than the curl, if you know what I’m saying …

20

Not sure what you’re saying at all. curl/libcurl is just an HTTP library. The TLS backend is configurable and it’s probably not a great idea to statically link it.

libcurl is happy to use the TLS provided by the OS on MacOS/Windows. Linux doesn’t have a standard, although OpenSSL is installed almost everywhere (and where it’s not, or you absolutely need static linking, you can use a static OpenSSL or one of the other backends supported by libcurl).

What you definitely do not want to do as a plugin is dynamically link libcurl or libssl and bundle the .so in your plugin bundle then write RPATH in the plugin binary to point to them with $ORIGIN (which is a way of controlling the loader search path from within a shared library). This will work in local testing but fail horribly if your plugin is loaded into a process that loads a different incompatible version of the same shared library - and since libcurl/libssl are used everywhere, that’s pretty likely.

Or you can ship an RPM and DEB and let the system package manager figure it out, which is how this problem is solved in practice for libraries with dependencies.

1 Like