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

Security Leftovers

10 hot Android smartphones that got price cuts recently

With numerous smartphone getting launched each month, brands always adjust prices to give slightly competitive edge to older smartphone models and also to clear inventories. Here are 10 smartphones that got price cuts recently. Read more

Debian and Ubuntu News

  • Debian Project News - July 29th, 2016
    Welcome to this year's third issue of DPN, the newsletter for the Debian community.
  • SteamOS Brewmaster 2.87 Released With NVIDIA Pascal Support
  • Snap interfaces for sandboxed applications
    Last week, we took a look at the initial release of the "portal" framework developed for Flatpak, the application-packaging format currently being developed in GNOME. For comparison, we will also explore the corresponding resource-control framework available in the Snap format developed in Ubuntu. The two packaging projects have broadly similar end goals, as many have observed, but they tend to vary quite a bit in the implementation details. Naturally, those differences are of particular importance to the intended audience: application developers. There is some common ground between the projects. Both use some combination of techniques (namespaces, control groups, seccomp filters, etc.) to restrict what a packaged application can do. Moreover, both implement a "deny by default" sandbox, then provide a supplemental means for applications to access certain useful system resources on a restricted or mediated basis. As we will see, there is also some overlap in what interfaces are offered, although the implementations differ. Snap has been available since 2014, so its sandboxing and resource-control implementations have already seen real-world usage. That said, the design of Snap originated in the Ubuntu Touch project aimed at smartphones, so some of its assumptions are undergoing revision as Snap comes to desktop systems. In the Snap framework, the interfaces that are defined to provide access to system resources are called, simply, "interfaces." As we will see, they cover similar territory to the recently unveiled "portals" for Flatpak, but there are some key distinctions. Two classes of Snap interfaces are defined: one for the standard resources expected to be of use to end-user applications, and one designed for use by system utilities. Snap packages using the standard interfaces can be installed with the snap command-line tool (which is the equivalent of apt for .deb packages). Packages using the advanced interfaces require a separate management tool.
  • Ubuntu 15.10 (Wily Werewolf) Reaches End Of Life Today (July 28)
  • Ubuntu MATE 16.10 Yakkety Yak Gets A Unity HUD-Like Searchable Menu
    MATE HUD, a Unity HUD-like tool that allows searching through an application's menu, was recently uploaded to the official Yakkety Yak repositories, and is available (but not enabled) by default in Ubuntu MATE 16.10.

Tablet review: BQ Aquaris M10 Ubuntu Edition

As employees have become more and more flexible in recent years thanks to the power and performance of mobile devices, the way we work has changed dramatically. We frequently chop and change between smartphones, tablets and laptops for different tasks, which has led to the growth of the hybrid market – devices such as Microsoft’s Surface Pro 3 and Apple’s iPad Pro – that provide the power and functionality of a laptop with the mobility and convenience of a tablet. Read more