Language Selection

English French German Italian Portuguese Spanish

One more reason not to trust CMake

Filed under
Software

So everybody says that CMake is great because it’s faster. Of course CMake achieves speed with an approach different from the one autotools have, that is, they don’t discover features, they apply knowledge. Hey it’s a valid method as any other, if you actually know what you are doing, and if you can keep up with variants and all the rest. Another thing that it does is to avoid the re-linking during the install phase.

Let me try to explain why re-linking exists: when you build a project using libtool, there might be binaries (executables and/or libraries) that depend on shared libraries that are being built in the same source tree. When you run the executables from the source tree, you want them to be used. When you install, as you might be installing just a subtree of the original software, libtool tries to guess if you just installed the library or not (often making mistakes) and if not, it re-links the target, that is, recreates it from scratch to link to the system library. In the case of packages built by ebuild, by the use of DESTDIR, we almost always have the relinking stage in there. Given that GNU ld is slow (and IMHO should be improved, rather than replaced by gold, but that’s material for another post), it’s a very wasteful process indeed, and libtool should be fixed not to perform that stage every time.

One of the things that the relinking stage is supposed to take care is to replace the rpath entries. An rpath entry specify to the runtime linker (ld.so) where to find the dependent libraries outside of the usual library paths (that is /etc/ld.so.conf and LD_LIBRARY_PATH). It’s used for non-standard install directories (for instance for internal libraries that should never be linked against) or during the in-tree execution of software, so that the just-built libraries are preferred over the ones in the system already.

So to make the install phase faster in CMake, they decided, with 2.6 series, to avoid the relinking, by messing with the rpath entries directly. It would be all fine and nice if they did it correctly of course.

MOre Here




More in Tux Machines

Leftovers: Software

  • Flowblade Video Editor 1.12 Released, Adds 2 New Tools
    A shiny new version of open-source video editor Flowblade is available for download. Flowblade 1.12 introduces a pair of new tools. Progress has also been made towards creating a distribution agnostic .AppImage, though, alas, there are still kinks to be ironed out so you won’t find an app image of the current release.
  • Vivaldi 1.8 Web Browser Launch Imminent As First Release Candidate Is Out
    Vivaldi's Ruarí Ødegaard announced today, March 24, 2017, the release and immediate availability of the first Release Candidate of the forthcoming Vivaldi 1.8 web browser for all supported platforms. Dubbed as Vivaldi Snapshot 1.8.770.44, the Release Candidate of Vivaldi 1.8 is here to fix some last-minute bugs for the new History feature, which is the star of the new upcoming web browser release based on the latest Chromium 57 open-source project, as well as to improve the user interface zoom functionality.
  • Epiphany 3.24 Web Browser Has New Bookmarks UI, Improves Tracking Protection
    GNOME 3.24 arrived a couple of days ago, and it's the biggest release of the popular desktop environment so far, shipping with lots of new features and improvements across all of its applications and components. During its 6-month development cycle, we managed to cover all the major features implemented in the GNOME 3.24 desktop environment, but also the various improvements included in many of the apps that are usually distributed under the GNOME Stack umbrella.
  • Firefox Sync Support Is Coming to GNOME Web
    GNOME Web (aka the browser formerly known as Epiphany) is working to add Firefox Sync support, letting users keep bookmarks, history and open-tabs in sync across devices.

Games and CrossOver

Red Hat and Fedora

Android Leftovers