Good, Bad and Ugly CURL

Curl is nice library for transferring anything from anywhere that have some kind of protocol over internet. It’s been stable for ages and have nice programming interface. So we thought this is easy new dependency for URW. We should know better.

User installed Ubuntu deb package and tried to launch URW in Arch received error  that was:

/usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found

Ok very nice and constructive error message. What to do? This in the dark side of Linux knowledge. If you search from web what this means you will notice there is plenty of packages that suffers from this. mostly they are proprietary like URW and build to work with Ubuntu and don’t work with Arch. It has something to do with openSSL and how old it is but that is far I debugged it.

ARGH ARCH!

So I installed Arch Virtualbox and started to research on this. So how to find it there ‘CURL_OPENSSL_3‘ in libcurl.so.4 or not. use ‘strings’ command (now you should say, “elementary dear Watson”, so you you don’t look stupid).

strings /usr/lib/libcurl.so.4 | grep CURL_OPENSSL_3

And no there is nothing with that name but

strings /usr/lib/libcurl.so.4 | grep CURL_OPENSSL_

Gives a shot. There is ‘CURL_OPENSSL_4‘ so what to do? You can’t do nothing if you don’t get very hazardous. You can sed ‘CURL_OPENSSL_4‘  to ‘CURL_OPENSSL_3‘ but there is no promises it will work and it’s not very convenient.

You can get Ubuntu deb, extract curl.so out of it and use LD_LIBRARY_PATH-variable (how to do that?  or use OpenSUSE version of URW that works out-of-the-box.

Nor of them is very elegant. Probably we’ll have to start building Arch package also because that is most elegant version of this.

But what are these “speedup’s” ? First, you’ve to know that in our build environment the ARM binaries are executed through an emulation-layer. This works on the cost of speed. The goal is now, to exchange some key parts in a transparent manner with native x86 binaries: no emulation, no slowdown. Sounds reasonable, but is it easily possible ?
I had to take care not to mix stuff too much because the environment would break. But now I’ve to say:  WOW, this worked incredibly well  .

The distinctive feature of our approach in comparison to usual cross-build environments is that we use the best of native environment emulation and the speed of cross-compilation. Because of this combination we don’t have to patch the individual packages to make them cross-compilation ready. This is a new way of cross-compiling suitable also for large number of packages. A detailed overview about the different crossbuild types can be found on this page.
Another feature to note is that the exchanged binaries (replacing ARM with x86 in the build environment) also don’t need heavy patching and there’s no need to compile them as static binaries. All of them are normal distribution packages.

A switch in the project enables/disables the new features. With the new changes in place, the speed could be vastly increased. Some figures:
* package rpm
* package glibc w/o locales

Thats a drop from about x15 to x2 in comparison to the native x86 build-time !! See it yourself when the “crosscompiled” repo in Base:build:arm is up and running.

In other words: “Warp 5, Mr. Sulu !”