Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Recommended way of using a custom build of libcurl in a Node.js addon
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Tue, 21 Mar 2023 07:48:00 -0400
On 21-Mar-23 04:34, Darshan Sen via curl-library wrote:
> Hi! I'd like to incorporate a custom build of libcurl (with HTTP3
> support) into a Node.js C++ addon <https://nodejs.org/api/addons.html>
> that is going to be shipped to some systems that don't have curl or
> its dependencies installed.
> From what I can tell, the possible ways in which this can be done are -
>
> * build a fully relocatable version of libcurl and the dependency
> libraries
> * statically compile libcurl into my application
>
> I'm not sure if there are any better solutions to this. What is the
> recommended way of doing this?
>
It depends. So you'll probably get several answers.
If you take either of the choices you suggest, you also take on the
maintenance task for libcurl and the libraries it depends on. That means
you'll have to update your addon whenever they have an issue that
affects your addon - including security issues.
The more components you ship, the greater the work you take on. And a
normal build of libcurl has quite a few dependencies. I only build a
subset, but a quick ldd on libcurl.so lists 26. (Of course, some will
be installed on most any system.) There is no unified schedule for
their releases, so across all the libraries, you may see an issue every
week. But the advantage is that your customers have a simple install,
and only one vendor (you) to deal with.
The alternative is to simply state that libcurl (and thus its
dependencies) is a dependency of your addon, and require that it's
installed. If you are distributing your addon via a package manager,
this is pretty simple - you specify libcurl and it's minimum version,
and the rest is handled automatically. The distributions enforce a
release schedule for the other libraries that consolidates the library
updates. The downside is you don't control the exact configuration of
libcurl, and your addon will probably encounter more versions of libcurl
than if you packaged it. libcurl has a stable API, but if you
accidentally (or intentionally) rely on undocumented behaviors, this
could be an issue.
Unless you have the resources to devote to supporting a private
distribution of libcurl et. al. for your customers, I'd simply make
libcurl a dependency. It's less work for you, and consistent with the
way most distributions work.
I'd have to see a very compelling use case to invest resources in a
private distribution. While it may seem simpler now, the long-term
costs tend to become large.
You'll have to decide what's best for you and your customers.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2023-03-21
Date: Tue, 21 Mar 2023 07:48:00 -0400
On 21-Mar-23 04:34, Darshan Sen via curl-library wrote:
> Hi! I'd like to incorporate a custom build of libcurl (with HTTP3
> support) into a Node.js C++ addon <https://nodejs.org/api/addons.html>
> that is going to be shipped to some systems that don't have curl or
> its dependencies installed.
> From what I can tell, the possible ways in which this can be done are -
>
> * build a fully relocatable version of libcurl and the dependency
> libraries
> * statically compile libcurl into my application
>
> I'm not sure if there are any better solutions to this. What is the
> recommended way of doing this?
>
It depends. So you'll probably get several answers.
If you take either of the choices you suggest, you also take on the
maintenance task for libcurl and the libraries it depends on. That means
you'll have to update your addon whenever they have an issue that
affects your addon - including security issues.
The more components you ship, the greater the work you take on. And a
normal build of libcurl has quite a few dependencies. I only build a
subset, but a quick ldd on libcurl.so lists 26. (Of course, some will
be installed on most any system.) There is no unified schedule for
their releases, so across all the libraries, you may see an issue every
week. But the advantage is that your customers have a simple install,
and only one vendor (you) to deal with.
The alternative is to simply state that libcurl (and thus its
dependencies) is a dependency of your addon, and require that it's
installed. If you are distributing your addon via a package manager,
this is pretty simple - you specify libcurl and it's minimum version,
and the rest is handled automatically. The distributions enforce a
release schedule for the other libraries that consolidates the library
updates. The downside is you don't control the exact configuration of
libcurl, and your addon will probably encounter more versions of libcurl
than if you packaged it. libcurl has a stable API, but if you
accidentally (or intentionally) rely on undocumented behaviors, this
could be an issue.
Unless you have the resources to devote to supporting a private
distribution of libcurl et. al. for your customers, I'd simply make
libcurl a dependency. It's less work for you, and consistent with the
way most distributions work.
I'd have to see a very compelling use case to invest resources in a
private distribution. While it may seem simpler now, the long-term
costs tend to become large.
You'll have to decide what's best for you and your customers.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature