libcurl Reporting Different Version Between Commands

Question

I previously had cURL 7.22.0 on Ubuntu 12.04 Server.. but I now need to upgrade to cURL 7.30.0.

I've done the following to compile this version for Ubuntu:

wget http://curl.haxx.se/download/curl-7.30.0.tar.gz

tar -xvzf curl-7.30.0.tar.gz

cd curl-7.30.0/

./configure --prefix=/usr

make clean

make

make install

After doing all that I ran curl --version expecting to see the new version installed. cURL had updated to 7.30.0 as expected, but libcurl hadn't:

curl 7.30.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 libssh2/1.2.8 librtmp/2.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

However, if I run curl-config --version I get libcurl 7.30.0 which is correct.

Can anyone explain why there's a difference in version numbers? And how to get them all showing the correct 7.30.0?

Does anyone have any tutorials / advice / any help at all on the proper way of upgrading everything cURL related to a later version. The topic seems to be incredibly lacking online, not sure why :/

Thanks

Edit - Following one of the comments, here's some additional info:

which curl-config gives /usr/bin/curl-config

which curl gives /usr/bin/curl

whereis curl gives curl: /usr/bin/curl /usr/include/curl /usr/share/man/man1/curl.1.gz /usr/share/man/man1/curl.1

whereis libcurl gives libcurl: /usr/lib/libcurl.a /usr/lib/libcurl.so /usr/lib/libcurl.la /usr/share/man/man3/libcurl.3

echo $PATH gives /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Answer 1

I'm reproducing a little tutorial I wrote for the zabbix wiki in the hope that it is useful.

Rebuilding a package from source in Debian and derivatives (Mepis, Mint, Ubuntu)

This guide will focus primarily in Debian, although building from source in other derivatives should be basically the same process. The upstream documentation on package management is ultimately the most authoritative source of wisdom.

Why should you choose packaging over "make install"?

Packages make your life easier in many aspects:

1. You can deploy packages easily on many systems by using a repository
2. You can install and remove them in a clean way
3. Dependencies on other packages are tracked for you
4. There's a policy for updating configuration files

Where are the source packages?/

Check what versions can be found in the official repositories of Debian and Ubuntu

This guide addresses the following scenarios

1. You are using Debian stable, and want to rebuild from source to change some default options
2. You are using Debian stable, and want to use the version in testing or unstable
3. You want to build a deb package from upstream sources
4. Alternatives to the official Debian packaging system

The rest of the guide will assume the commands are being run by a non-root user with sudo access

$ sudo -l

• Activate the source repository, in your sources.list

• Install the required infrastructure for building, recompiling and packaging

  $ sudo aptitude install build-essentials devscripts quilt

1. You are using Debian stable, and want to rebuild the sources

This would be the case when you want to activate/deactivate some feature that's built by default in the precompiled binaries, apply an extra patch, backport a feature, use compile-time optimizations (target an specific platform, hardening options). The steps would be:

Create a temporary directory to work in

$ mkdir ~/temp && cd ~/temp

Get the source package

$ apt-get source curl 

or alternatively (if you don't have a deb-src line in your sources.list pointing to the stable release), you can get the .dsc file from the web, for current stable this would be

$ dget http://security.debian.org/debian-security/pool/updates/main/c/curl/curl_7.21.0-2.1+squeeze3.dsc 

Any of the two alternative methods will

1. fetch the sources from the repositories
2. validate the cryptographic signature of the package
3. apply all distro specific patches

Check the debian/rules makefile

$ cd curl*
$ vi debian/rules

This is the main makefile for the packaging process, here you can review optional configure options, and can also enable/disable features regarding all the packages that will be built (server, agent, proxy)

Review the patches with quilt

Let's suppose you are interested in one or more of the distro patches not being applied. To check what patches are available in the sources, use

$ quilt series

Check for the already applied patches (at this stage the list should be identical)

$ quilt applied

Revert all the patches

$ quilt pop -a

Optionally remove the unwanted ones

$ quilt delete -r $patch_name

Apply the rest of the patches

$ quilt push -a

Install the dependencies of the package you are going to recompile

$ apt-get build-dep curl

Optionally tag the package

$ dch -l +local 'Rebuilt from sources'

Check the dch manpage if you need to add a more elaborated changelog entry.

Finally, recompile the package

$ debuild -us -uc

After the process, outside the zabbix-* directory, you will find the deb packages you just compiled, ready to install

$ sudo dpkg -i $deb_package

2. You are using Debian stable, and want to use the version in testing or unstable

This process is known as backporting

The following precautions apply

• The package might not build for you at all
• In order to build it might need updated dependencies
• In order to build it might need additional packages
• The packaging layout might have changed

The process is the same as rebuilding for the stable release, with the exception of the source package, which can be obtained either from apt repositories using a line like this in your sources.list (note, only one of the two alternatives)

deb-src http://ftp.de.debian.org/debian/ testing main non-free contrib
deb-src http://ftp.de.debian.org/debian/ unstable main non-free contrib

or again, using the web

$ dget http://ftp.de.debian.org/debian/pool/main/c/curl/curl_7.30.0-1.dsc

An extra precaution would be tagging the packages to ease identification in case uninstallation is needed.

$ dch -l ~local 'Sid backport'

The rest of the process is identical, and the result will be backported packages that can be installed along the rest.

3. You want to build a deb package from upstream sources

If you want or need a more recent version than the one that can be found in Sid, you can still check the experimental repository, and the git repository of the mantainer(s) to see if there's something in the works. Beyond that, you need to use the upstream project repo, but yet one can benefit from the Debian packaging structure. To that end, a snapshot of the latest stable or alpha release can be downloaded. So, after having downloaded the source package from the distro (Debian or Ubuntu, as appropriate) repo as outlined above, the next steps would be (differences in the versions in use might apply):

 $ wget https://github.com/bagder/curl/archive/curl-7_30_0.zip
 $ mv master.zip curl-7.30.0.zip
 $ cd curl-${stable}
 $ uupdate ../curl-7.30.0.zip -v 7.30.0
 $ cd ../curl-7.30.0

After this, all the patches in the debian/patches must be reviewed in order to determine if they still are useful or have to be discarded. Use quilt as described above. Finish the recompile process tagging

$ dch -l ~local 'Upstream packaging'

rebuilding

$ debuild -us -uc

and installing

$ sudo dpkg -i $deb_package

the package(s).

4. Alternatives to the official Debian packaging system

Some people find the Debian packaging system excessively complicated but still want to benefit from the advantages of using a packaged software. Some projects exist that try to address this situation. A list is given here, but the details of using these tools is left as an exercise for the reader.

• checkinstall
• fpm and its companion tool fpm-cookery