Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

GCC 5 in Fedora

February 10, 2015
Jeff Law Jonathan Wakely Matt Newsome Jakub Jelínek Jason Merrill

Share:

    gnu logoFedora 22 will ship with GCC 5, which brings a whole host of enhancements, among which is a new default C++ ABI. In this article, we'll cover how that ABI transition will work in Fedora.

    Background - what's an ABI, why is it changing, and what does this mean for developers?

    Put simply, binary compatibility means applications that are compiled on a combination of an operating system and a particular hardware architecture will load and run similarly across different instances of the operating environment. Application binaries consist of executable files and Dynamic Shared Objects (DSOs - the formal name for shared libraries), and the level of compatibility is defined by a specific application binary interface (ABI).

    The development of new features in compilers, libraries and related tools - and notably any new language standard those tools support - can result in changes to the ABI, requiring that certain binaries need to be re-built, or that newly built binaries are not directly compatible with existing binaries.

    GCC 5 implements such an ABI change when the compiler is built with default options from the upstream community sources. It does this order to implement the new C++11 language standard. That provides new features to developers at the cost of binary compatibility - the C++11 requirements on certain C++ core classes requires an ABI change.

    GCC 5 also provides, out of the box, a compiler switch to switch back to using the older ABI by default, at the cost of some C++11 conformance. Whichever ABI GCC is configured to use by default, developers can use the other one on a per-file basis by defining a macro to override the default.

    FESCo's decision and rationale around GCC 5 and Fedora 22

    In mid-January, the maintainer of GCC in Fedora made a proposal for GCC 5 to be included in Fedora 22. That proposal was made to FESCo,the body that has overall authority to determine what major features get into each release of Fedora.

    The issue was debated during the recent FESCo meetings, which the maintainer attended, and ultimately the decision was made to ship GCC 5, but with
    the old ABI enabled by default.

    At the heart of this decision was the priority placed by FESCo on the Fedora 22 schedule.  A mass rebuild of all Fedora packages would not be possible if Fedora 22 is to ship on time. A "mini-mass-rebuild" was considered, where only C++ packages would be rebuilt (so Fedora could move to using C++11 and the new ABI).  The idea here would be to reduce the number of packages that must be rebuilt to save time.  That proposal was also rejected, however, as FESCo felt even the mini-mass-rebuild would impact the Fedora 22 schedule.

    That left FESCO with two options.  Either to remain with GCC 4.9 through the Fedora 22 cycle, then upgrade to GCC 5 in Fedora 23, or to use GCC 5, but with the old C++ ABI in Fedora 22, then step forward with the new ABI in Fedora 23.

    Staying with GCC 4.9 would have minimized the work required for Fedora 22 GCC packaging, Fedora 22. The Fedora and GCC development cycles are mutually beneficial, however, and so removing GCC 5 from Fedora has side effects in terms of GCC 5's development upstream.

    Staying with GCC 4.9 would also leave Fedora users without easy access to all the other benefits GCC 5 brings. The removal of GCC 5 could even be misconstrued as signalling that GCC 5 wasn't ready for production use.

    Finally, staying with GCC 4.9 would also impact developers using Red Hat's tools for RHEL, such as Red Hat Developer Toolset - GCC 5 wouldn't have the widespread Fedora testing Red Hat desires before addition to Red Hat's product portfolio.

    The option to use GCC 5, but with the old ABI, allows developers to benefit from all the upstream community's work on features and bugfixes. Those active users in turn benefit both the GCC and Fedora projects directly. Fedora will not enable the new C++11 ABI by default, but that will also allow developers to handle the general upgrade to GCC 5 separately to the new ABI, which is expected to be enabled in Fedora 23.

    So what do I need to know about Fedora 22 and Fedora 23 as a developer?

    One consequence of this decision will be that Fedora 22 and Fedora 23 will both have GCC 5, but they'll be fundamentally different. The C++ library (libstdc++.so) will be
    compatible between F22 and F23 (in fact, it will be almost exactly the same,
    modulo some extra patches from upstream that might be pulled into the later F23 build). The difference will be all the other DSOs that link to it. That's important for Fedora developers to note.

    Specifically, FESCo's decision means the C++ standard library headers installed by the
    libstdc++-devel RPM will have a different default value for the _GLIBCXX_USE_CXX11_ABI macro (0 in F22 and 1 in F23) but the libstdc++.so library will be largely the same in F22 and F23, because that library contains all the symbol definitions for both the old ABI and the new ABI, so that the same library works for both cases.

    However, when another DSO such as libboost_filesystem.so is compiled with GCC 5 it will be compiled using either the old ABI or the new one, but not both, and programs linking to that DSO will usually need to use the same ABI to avoid linker errors. The C++ libraries that are part of Fedora 22 will be built using the old ABI, but they will be built using the new ABI in Fedora 23. Developers might need to recompile their programs using the new ABI in order to link to C++ libraries in Fedora 23. Similarly, developers who use the _GLIBCXX_USE_CXX11_ABI macro to override the default might need to rebuild other libraries they depend on to ensure those libraries are also built with the non-default ABI.

    If you happen to maintain a package in Fedora that provides a library for consumption by other packages, you might even consider doing something similar to libstdc++ for Fedora 22/23, i.e. provide two sets of your public symbols - one for the old ABI and one for the new ABI. Whether that would be worth the effort to implement depends largely on the number of consumers of your library, the number of symbols your library contains, and how sensitive your users are to ABI changes. Essentially, you need to work out which symbols are affected. One way to do this is to build for C++98 [gcc -D_GLIBCXX_USE_CXX11_ABI=0 -Wabi-tags in your rpmbuild], then separately for C++11 [gcc -D_GLIBCXX_USE_CXX11_ABI=1 -Wabi-tags in your rpmbuild], and then compare the two DSOs with abidiff (part of libabigail) [abidiff old-abi/libfoo.so new-abi/libfoo.so]. Having identified the symbols affected, make sure those symbols are compiled in their own files separately from unaffected symbols, so you can compile them twice (without duplicates of the unaffected symbols). It's non-trivial, but something to consider.

    Overall, there are three key things to keep in mind about GCC 5 in Fedora 22. Firstly, the Fedora 22 GCC component will still be from a full upstream release. Secondly, selection of the ABI is done by way of a standard configure time flag - the option is there to rebuild with that switch reversed. Thirdly, ABI compatibility with F21 is actually maintained in Fedora 22 (though developers will have the option to enable the newer C++11 ABI via -D_GLIBCXX_USE_CXX11_ABI=1).

    What does this mean for RHEL developers?

    Developers building applications for Red Hat Enterprise Linux, using Red Hat tools to build binaries and shared libraries, are unaffected by these changes.

    Final Thoughts

    Hopefully this article has been useful in explaining what the plan is for GCC 5's release in Fedora, how FESCo arrived at their decision, and what it means for Fedora and Red Hat Enterprise Linux developers.

    Feel free to ask questions or provide feedback.

    Last updated: June 11, 2017

    Recent Posts

    • Integrate Red Hat AI Inference Server & LangChain in agentic workflows

    • Streamline multi-cloud operations with Ansible and ServiceNow

    • Automate dynamic application security testing with RapiDAST

    • Assessing AI for OpenShift operations: Advanced configurations

    • OpenShift Lightspeed: Assessing AI for OpenShift operations

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue