Programming Languages

2 tips to make your C++ projects compile 3 times faster

2 tips to make your C++ projects compile 3 times faster

In this article, I will demonstrate how to speed up your compilation times by distributing compilation load using a distcc server container.  Specifically, I’ll show how to set up and use containers running a distcc server to distribute the compilation load over a heterogeneous cluster of nodes (development laptop, old desktop PC, and a Mac). To improve the speed of recompilation, I will use ccache.

Continue reading “2 tips to make your C++ projects compile 3 times faster”

Share
Use the Kubernetes Python client from your running Red Hat OpenShift pods

Use the Kubernetes Python client from your running Red Hat OpenShift pods

Red Hat OpenShift is part of the Cloud Native Computing Foundation (CNCF) Certified Program, ensuring portability and interoperability for your container workloads. This also allows you to use Kubernetes tools to interact with an OpenShift cluster, like kubectl, and you can rest assured that all the APIs you know and love are right there at your fingertips.

The Kubernetes Python client is another great tool for interacting with an OpenShift cluster, allowing you to perform actions on Kubernetes resources with Python code. It also has applications within a cluster. We can configure a Python application running on OpenShift to consume the OpenShift API, and list and create resources. We could then create containerized batch jobs from the running application, or a custom service monitor, for example. It sounds a bit like “OpenShift inception,” using the OpenShift API from services created using the OpenShift API.

In this article, we’ll create a Flask application running on OpenShift. This application will use the Kubernetes Python client to interact with the OpenShift API, list other pods in the project, and display them back to the user.

Continue reading “Use the Kubernetes Python client from your running Red Hat OpenShift pods”

Share
How C array sizes become part of the binary interface of a library

How C array sizes become part of the binary interface of a library

Most C compilers allow accessing an array declared extern, which has indeterminate bounds, like this:

extern int external_array[];

int
array_get (long int index)
{
  return external_array[index];
}

The definition of external_array could reside in a different translation unit and look like this:

int external_array[3] = { 1, 2, 3 };

The question is what happens if this separate definition is changed to this:

int external_array[4] = { 1, 2, 3, 4 };

Or this:

int external_array[2] = { 1, 2 };

Does either change preserve the binary interface (assuming that there is a mechanism that allows the application to determine the size of the array at run time)?

Curiously, the answer is that on many architectures, increasing the array size breaks binary interface (ABI) compatibility. Decreasing the array size may also cause compatibility problems. We’ll look more closely at ABI compatibility in this article and explain how to avoid problems.

Continue reading “How C array sizes become part of the binary interface of a library”

Share
Stack Clash mitigation in GCC: Why -fstack-check is not the answer

Stack Clash mitigation in GCC: Why -fstack-check is not the answer

In our previous article about Stack Clash, we covered the basics of the Stack Clash vulnerability. To summarize, an attacker first uses various means to bring the heap and stack close together. A large stack allocation is then used to “jump the stack guard.” Subsequent stores into the stack may modify objects in the heap or vice versa. This, in turn, can be used by attackers to gain control over applications.

GCC has a capability (-fstack-check), which looked promising for mitigating Stack Clash attacks. This article will cover how -fstack-check works and why it is insufficient for mitigating Stack Clash attacks.

Continue reading “Stack Clash mitigation in GCC: Why -fstack-check is not the answer”

Share
Use Node.js 12 on Red Hat OpenShift today

Use Node.js 12 on Red Hat OpenShift today

On April 23, Node.js released its latest major version with Node.js 12. Because this is an even-numbered release, it will become a Long Term Support (LTS) release in October, code-named Erbium.

This release brings a host of improvements and features, which this blog post isn’t going to cover. Instead, I will focus on how to start using this new release today on Red Hat OpenShift. If you’re interested in more about the various improvements and new features, check out the articles listed at the end of this post.

Continue reading “Use Node.js 12 on Red Hat OpenShift today”

Share
Optimizing Red Hat Fuse 7 Spring Boot container images

Optimizing Red Hat Fuse 7 Spring Boot container images

Working with Red Hat Fuse 7 on Spring Boot is straightforward. In my field experience, I have seen many development (a.k.a. integrator) teams moving to Fuse 7 on Spring Boot for their new integration platforms on Red Hat OpenShift Container Platform (well aligned with agile integration).

Lately, however, I have also seen some teams worried about the size of the final images and the deployment pipeline. In most cases, they had developed a set of common libraries or frameworks to extend or to homogenize the final integration projects. All the cases have the same result:

  • Several dependencies copied in each integration project
  • Always replacing the container images with the latest fat JAR (including the same dependencies) in each build pipeline

Spring Boot is usually packaged as “fat JARS” that contain all runtime dependencies. Although this is quite convenient, because you only need a JRE and a single JAR to run the application, in a container environment such as Red Hat OpenShift, you have to build a full container image to deploy your application.

Continue reading “Optimizing Red Hat Fuse 7 Spring Boot container images”

Share
Red Hat Developer Toolset 8.1 Beta now available

Red Hat Developer Toolset 8.1 Beta now available

Red Hat Developer Toolset augments Red Hat Enterprise Linux with the latest, stable versions of GCC that install alongside the original base version. This version of Red Hat Developer Toolset 8.1 Beta includes the following new components:

  • GCC 8.2.1
  • GDB 8.2
  • binutils 2.30
  • elfutils 0.176
  • Valgrind 3.14.0

This Beta release is supported on Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 for AMD64 and Intel 64 architectures. It also supports the following architectures on Red Hat Enterprise Linux 7:  64-bit ARM, big- and little-endian variants of IBM POWER (), and IBM Z. See below for more information about each updated component.

Continue reading “Red Hat Developer Toolset 8.1 Beta now available”

Share
Red Hat Software Collections 3.3 Beta: New and updated components

Red Hat Software Collections 3.3 Beta: New and updated components

Red Hat Software Collections supply the latest, stable versions of development tools for Red Hat Enterprise Linux via two release trains per year. We are pleased to introduce three new and two updated components in this release, Red Hat Software Collections 3.3 Beta.

The new components are:

  • Ruby 2.6
  • MariaDB 10.3 featuring a new MariaDB Connector for Java
  • Redis 5.0

The updated items include:

  • Two updates to Apache httpd
  • One update to HAProxy

See below for component details.

Continue reading “Red Hat Software Collections 3.3 Beta: New and updated components”

Share
Understanding when not to std::move in C++

Understanding when not to std::move in C++

One of the most important concepts introduced in C++11 was move semantics. Move semantics is a way to avoid expensive deep copy operations and replace them with cheaper move operations. Essentially, you can think of it as turning a deep copy into a shallow copy.

Move semantics came along with several more or less related features, such as rvalue references, xvalues, forwarding  references, perfect forwarding, and so on. The standard C++ library gained a function template called std::move, which, despite its name, does not move anything. std::move merely casts its argument to an rvalue reference to allow moving it, but doesn’t guarantee a move operation. For example, we can write a more effective version of swap using std::move:

template<typename T>
void swap(T& a, T& b)
{
  T t(std::move (a));
  a = std::move (b);
  b = std::move (t);
}

This version of swap consists of one move construction and two move assignments and does not involve any deep copies. All is well. However, std::move must be used judiciously; using it blithely may lead to performance degradation, or simply be redundant, affecting readability of the code. Fortunately, the compiler can sometimes help with finding such wrong uses of std::move. In this article, I will introduce two new warnings I’ve implemented for GCC 9 that deal with incorrect usage of std::move.

Continue reading “Understanding when not to std::move in C++”

Share