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
Best Answer
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:
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
The rest of the guide will assume the commands are being run by a non-root user with sudo access
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
Get the source package
or alternatively (if you don't have a
deb-src
line in yoursources.list
pointing to the stable release), you can get the .dsc file from the web, for current stable this would beAny of the two alternative methods will
Check the debian/rules makefile
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
Check for the already applied patches (at this stage the list should be identical)
Revert all the patches
Optionally remove the unwanted ones
Apply the rest of the patches
Install the dependencies of the package you are going to recompile
Optionally tag the package
Check the dch manpage if you need to add a more elaborated changelog entry.
Finally, recompile the package
After the process, outside the zabbix-* directory, you will find the deb packages you just compiled, ready to install
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 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)
or again, using the web
An extra precaution would be tagging the packages to ease identification in case uninstallation is needed.
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):
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
rebuilding
and installing
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.