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

How Red Hat is making money on the public cloud with a hybrid approach

Red Hat hasn't traditionally played much of a part in public clouds, a fact its CEO Jim Whitehurst underscored in Red Hat's recent earnings call. Though the company is now dabbling in a true elastic/consumption-based delivery and pricing model via OpenShift, Red Hat remains a primarily on-premises business that only feints toward a true cloud model in terms of service delivery. Ironically, the hybrid cloud may be the trend that gets Red Hat fully planted in the public cloud. Read more

GE, Bosch and open source could bring more IoT tools

The two companies, both big players in industrial IoT, said they will establish a core IoT software stack based on open-source software. They plan to integrate parts of GE's Predix operating system with the Bosch IoT Suite in ways that will make complementary software services from each available on the other. The work will take place in several existing open-source projects under the Eclipse Foundation. These projects are creating code for things like messaging, user authentication, access control and device descriptions. Through the Eclipse projects, other vendors also will be able to create software services that are compatible with Predix and Bosch IoT Suite, said Greg Petroff, executive director of platform evangelism at GE Software. Read more

Unsafe at any clock speed: Linux kernel security needs a rethink

The Linux kernel today faces an unprecedented safety crisis. Much like when Ralph Nader famously told the American public that their cars were "unsafe at any speed" back in 1965, numerous security developers told the 2016 Linux Security Summit in Toronto that the operating system needs a total rethink to keep it fit for purpose. No longer the niche concern of years past, Linux today underpins the server farms that run the cloud, more than a billion Android phones, and not to mention the coming tsunami of grossly insecure devices that will be hitched to the Internet of Things. Today's world runs on Linux, and the security of its kernel is a single point of failure that will affect the safety and well-being of almost every human being on the planet in one way or another. Read more

Linux Foundation and Linux

  • ONOS Hummingbird SDN release touts core control function improvements
    ON.Lab’s ONOS Project noted its eighth SDN platform release expands southbound and northbound protocol, legacy device support The telecommunications market’s choice of software-defined networking platforms continues to blossom, with the Open Networking Laboratory’s Open Network Operating System Project releasing its latest SDN platform variant under the “Hummingbird” tag.
  • OPNFV Heads Down Colorado Trail
    OPNFV today issued its third software release, ending the agonizing six-month period in which folks had to pronounce and spell Brahmaputra. (See OPNFV Issues Third Software Release.) This latest release continues the river theme but is sensibly named Colorado: It has other advantages as well, namely support for key features such as security, IPv6, service function chaining (SFC) testing, virtual private networks and more. In addition, Colorado is laying some key groundwork for what lies ahead as the industry comes to terms with the MANO (management and network orchestration) dilemma, says Heather Kirksey, Open Platform for NFV Project Inc. 's executive director.
  • OPNFV's Third Release Includes Security Enhancements
  • ONOS, OPNFV Introduce Latest Open SDN, NFV Releases
  • OPNFV Issues Third Software Release
  • The Linux State Of AMD's Zen x86 Memory Encryption
    With AMD's forthcoming Zen processors is support for some new memory encryption technologies that are of particular benefit for virtualized environments. I wrote about Linux patches for AMD memory encryption earlier this year while since then more information has come to light. At last month's Linux Security Summit, David Kaplan presented on these technologies coming with Zen; only today I had come across the slide deck for this presentation. The technologies come down to Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV). SME provides memory encryption on a per-page-table basis using AMD's ARM-based security co-processor. AMD SME + SEV are designed against both user-access attacks and physical access attacks with a particular focus on VM / hypervisor security.
  • Improving Fuzzing Tools for More Efficient Kernel Testing
    Fuzz testing (or fuzzing) is a software testing technique that involves passing invalid or random data to a program and observing the results, such as crashes or other failures. Bamvor Jian Zhang of Huawei, who will be speaking at LinuxCon Europe, realized that existing fuzz testing tools -- such as trinity -- can generate random or boundary values for syscall parameters and inject them into the kernel, but they don’t validate whether the results of those syscalls are correct.
  • X.Org's GLAMOR 2D Performance Continues To Be Tuned
    While GLAMOR has already been around for a number of years as a means of providing generic X11 2D acceleration over OpenGL for the X.Org Server, it's a seemingly never-ending process to optimize its code-paths for best performance. More improvements are en route for making GLAMOR 2D faster, which should especially be helpful for Raspberry Pi users making use of the VC4 driver stack on this very slow-speed hardware. Benefits to the GLAMOR code in the X.Org Server obviously have the potential to benefit all users of this acceleration mechanism for code going into the xorg-server code-base as opposed to an individual GL driver, but for Raspberry Pi users in particular there is some efforts ongoing by Broadcom's Eric Anholt as well as Keith Packard's never-ending tinkering with the X Server code. GLAMOR continues to be used by default for all AMD GCN GPUs, Nouveau for the latest generations of GPU too, VC4 2D is only supported with GLAMOR, and optionally by other DDX drivers too.