Separate install

At times when you build curl and libcurl from source, you do this with thepurpose of experimenting, testing or perhaps debugging. In these scenarios,you might not be ready to replace your system wide libcurl installation.

Many modern systems already have libcurl installed in the system, so when youbuild and install your test version, you need to make sure that your new buildis used for your purposes.

We get a lot of reports from people who build and install their own version ofcurl and libcurl, but when they subsequently invoke their new curl build, thenew tool finds an older libcurl in the system and instead uses that. Thistends to confuse users.

Static linking

You can avoid the problem of curl finding an older dynamic libcurl library byinstead linking with libcurl statically. This however instead triggers a slewof other challenges because linking modern libraries with several third partydependencies statically is hard work. When you link statically, you need tomake sure you provide all the dependencies to the linker. This is not a methodwe recommend.

Dynamic linking

When you invokecurl on a modern system, there is a runtime linker (oftencalledld.so) that loads the shared libraries the executable was built touse. The shared libraries are searched for and loaded from a set of paths.

The problem is often that the system libcurl library exists in that path,while your newly built libcurl does not. Or they both exist in the path butthe system one is found first.

The runtime linker path order is typically defined in/etc/ld.so.conf onLinux systems. You can change the order and you can add new directories to thelist of directories to search. Remember to runldconfig after an update.

Temporary installs

If you build a libcurl and install it somewhere and you just want to use itfor a single application or maybe just to test something out for a bit,editing and changing the dynamic library path might be a bit too intrusive.

A normal unix offers a few other alternative takes that we recommend.

LD_LIBRARY_PATH

You can set this environment variable in your shell to make the runtimelinker look in a particular directory. This affects all executables loadedwhere this variable is set.

It is convenient for quick checks, or even if you want to rotate around andhave your singlecurl executable use different libcurls in differentinvokes.

It can look like this when you have installed your new curl build in$HOME/install:

export LD_LIBRARY_PATH=$HOME/install/lib$HOME/install/bin/curl https://example.com/

rpath

Often, a better way to forcibly load your separate libcurl instead of thesystem one, is to set therpath of the specificcurl executable youbuild. That gives the runtime linker a specific path to check for thisspecific executable.

This is done at link time, and if you build your own libcurl usingapplication, you can make that load your custom libcurl build like this:

gcc -g example.c -L$HOME/install/lib -lcurl -Wl,-rpath=$HOME/install/lib

Withrpath set, the executable linked against$HOME/install/lib/libcurl.sothen makes the runtime linker use that specific path and library, while otherbinaries in your system continue to use the system libcurl.

When you want to make your custom build ofcurl use its own libcurl and youinstall them into$HOME/install, then a configure command line for thislooks something like this:

LDFLAGS="-Wl,-rpath,$HOME/install/lib" ./configure ...

If your system supports the runpath form of rpath it is often better to usethat instead because it can be overridden by theLD_LIBRARY_PATH environmentvariable. It may also prevent libtool bugs when testing in-tree builds of curl,since then libtool can useLD_LIBRARY_PATH. Newer linkers may use the runpathform of rpath by default when rpath is specified but others need an additionallinker flag-Wl,--enable-new-dtags like this:

LDFLAGS="-Wl,-rpath,$HOME/install/lib -Wl,--enable-new-dtags" \  ./configure ...