Skip to main content
AI
  • Get started with AI

    • Red Hat AI

      Accelerate the development and deployment of enterprise AI solutions.

    • AI learning hub

      Explore learning materials and tools, organized by task.

    • AI interactive demos

      Click through scenarios with Red Hat AI, including training LLMs and more.

    • AI/ML learning paths

      Expand your Red Hat OpenShift AI knowledge using these learning resources.

    • AI quickstarts

      Focused AI use cases designed for fast deployment on Red Hat AI platforms.

    • No-cost AI training

      Foundational Red Hat AI training.

  • Featured resources

    • Red Hat OpenShift AI
    • Open source AI for developers
    • AI product application development
    • Open source-powered AI/ML for hybrid cloud
    • AI and Node.js cheat sheet

Red Hat AI Factory with NVIDIA

Red Hat AI Factory with NVIDIA is a co-engineered, enterprise-grade AI solution for building, deploying, and managing AI at scale across hybrid cloud environments.

Learn
  • Self-guided

    • Documentation

      Find answers, get step-by-step guidance, and learn how to use Red Hat products.

    • Learning paths

      Explore curated walkthroughs for common development tasks.

    • Guided learning

      Receive custom learning paths powered by our AI assistant.

    • See all learning
  • Hands-on

    • Developer Sandbox

      Spin up Red Hat's products and technologies without setup or configuration.

    • Interactive labs

      Learn by doing in these hands-on, browser-based experiences.

    • Interactive demos

      Click through product features in these guided tours.

  • Browse by topic

    • AI/ML
    • Automation
    • Java
    • Kubernetes
    • Linux
    • See all topics
  • Training & certifications

    • Courses and exams
    • Certifications
    • Skills assessments
    • Red Hat Academy
    • Learning subscription
    • Explore training
Build
  • Get started

    • Red Hat build of Podman Desktop

      A downloadable, local development hub to experiment with our products and builds.

    • Developer Sandbox

      Spin up Red Hat's products and technologies without setup or configuration.

  • Download products

    • Red Hat Enterprise Linux
    • Red Hat AI
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform
    • See all products
  • Featured

    • Red Hat build of OpenJDK
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat Developer Toolset
  • References

    • E-books
    • Documentation
    • Cheat sheets
    • Architecture center
Community
  • Get involved

    • Events
    • Live AI events
    • Red Hat Summit
    • Red Hat Accelerators
    • Community discussions
  • Follow along

    • Articles & blogs
    • Developer newsletter
    • Videos
    • Github
  • Get help

    • Customer service
    • Customer support
    • Regional contacts
    • Find a partner

Join the Red Hat Developer program

Download Red Hat products and project builds, access support documentation, learning content, and more.

ConsoleDocsSupport Search
New For you

Recommended

We'll recommend resources you may like as you browse. Try these suggestions for now.

  • Product downloads
  • Cheat sheets
  • Red Hat Developer learning portal
  • Developer blog
  • E-books
  • Developer Sandbox
Log in

Get more with a Red Hat Developer account

  • Product downloads
  • Console access
  • Event registration
  • Training & trials
Explore more account benefitsLog in or register

A subscription may be required for some services.

Contact us

ABI change analysis of Fedora packages

February 28, 2017
Dodji Seketeli
Related topics:
Developer toolsLinuxSecurity
Related products:
Red Hat Enterprise Linux

    In 2016, many improvements happened in the ABI static analysis framework that is Libabigail. In this article we'll present how fedabipkgdiff, a new Libabigail tool can help Fedora users, developers and others to analyze ABI changes of libraries carried by packages of the distribution.

    Introduction

    As many of you already know, the engine used to build RPM packages in the Fedora build system is named Koji. Thus, one can get Fedora RPMs from Koji using a web browser. In that case, it's easy enough to go to https://koji.fedoraproject.org/koji/ and use the search text box on that page to look for a given package that carries libraries we want to analyze ABI changes for.

    For instance, let's say that throughout this article, we want to analyze the ABI changes that happened to the libraries of the latest stable spice-server package between Fedora 23 and Fedora 25.

    If we were to do this without fedabipkgdiff, I guess we'd have to use the abipkgdiff tool. That tool needs the two packages to compare (the spice-server from fedora 23 and the one from Fedora 25) and their associated debug information packages. That makes 4 packages to download from Koji, by hand.

    We could even add the development packages that contain the header files of the shared libraries carried by the spice-server packages. abipkgdiff might need these development packages to filter out ABI changes coming from changes to types that are not defined in the public headers of the library. In other words, filter out changes to types that are private to the library.

    So with these two additional development packages, that makes 6 packages to download from Koji, by hand.

    Once we have downloaded those six packages, the invocation of abipkgdiff would look like:

    abipkgdiff --debug-info-pkg1 spice-server-debuginfo-<from-fedora23>.rpm \
     --debug-info-pkg2 spice-server-debuginfo-<from-fedora25>.rpm \
     --devel-pkg1 spice-server-devel-<from-fedora23>.rpm \
     --devel-pkg2 spice-server-devel-<from-fedora25>.rpm \
     spice-server-<from-fedora23>.rpm \
     spice-server-<from-fedora25>.rpm

    One still has to figure out what the exact names of the latest "stable" RPMs are for Fedora 23 and Fedora 25. And that is for just one architecture.

    In all fairness, as the old saying goes, there's gotta be a better way.

    fedabipkgdiff: a friendly broker to Koji

    It turns out that Koji does have a programmatic interface. So one can use the Koji API to discover the exact full name of the latest stable package, the associated development package or the associated debug info package. And that, for each architecture.

    And this is where fedabipkgdiff kicks in. It acts as a proxy between the user who asks questions like "what are the ABI changes between Fedora 23 and 25 for the spice-server" and the Koji server. It thus downloads the packages to compare along with all their necessary ancillary packages, for all the available architectures. It then uses the abipkgdiff tool under the hood to perform the comparisons of the packages.

    Invocation

    "What are the ABI changes between Fedora 23 and 25 for the spice-server package?".

    The command line equivalent to that question, using fedabipkgdiff, is exactly:

    fedabipkgdiff --from fc23 --to fc25 spice-server

    Interested readers will hopefully appreciate the compactness of this approach compared to the previous approach of downloading all the necessary packages by hand and using abipkgdiff directly.

    Analyzing the results

    Here is what fedabipkgdiff actually says:

    $ fedabipkgdiff --from fc23 --to fc25 spice-server
    
    Comparing the ABI of binaries between spice-server-0.12.8-1.fc23.armv7hl.rpm and spice-server-0.13.3-2.fc25.armv7hl.rpm:
    
    ================ changes of 'libspice-server.so.1.10.1'===============
     Functions changes summary: 0 Removed, 0 Changed (85 filtered out), 3 Added functions
     Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
    
    3 Added functions:
    
    'function void spice_qxl_gl_draw_async(QXLInstance*, uint32_t, uint32_t, uint32_t, uint32_t, uint64_t)' {spice_qxl_gl_draw_async@@SPICE_SERVER_0.13.1}
     'function void spice_qxl_gl_scanout(QXLInstance*, int, uint32_t, uint32_t, uint32_t, uint32_t, int)' {spice_qxl_gl_scanout@@SPICE_SERVER_0.13.1}
     'function int spice_server_set_video_codecs(SpiceServer*, const char*)' {spice_server_set_video_codecs@@SPICE_SERVER_0.13.2}
    
    ================ end of changes of 'libspice-server.so.1.10.1'===============
    
    Comparing the ABI of binaries between spice-server-0.12.8-1.fc23.i686.rpm and spice-server-0.13.3-2.fc25.i686.rpm:
    
    ================ changes of 'libspice-server.so.1.10.1'===============
     Functions changes summary: 0 Removed, 0 Changed (85 filtered out), 3 Added functions
     Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
    
    3 Added functions:
    
    'function void spice_qxl_gl_draw_async(QXLInstance*, uint32_t, uint32_t, uint32_t, uint32_t, uint64_t)' {spice_qxl_gl_draw_async@@SPICE_SERVER_0.13.1}
     'function void spice_qxl_gl_scanout(QXLInstance*, int, uint32_t, uint32_t, uint32_t, uint32_t, int)' {spice_qxl_gl_scanout@@SPICE_SERVER_0.13.1}
     'function int spice_server_set_video_codecs(SpiceServer*, const char*)' {spice_server_set_video_codecs@@SPICE_SERVER_0.13.2}
    
    ================ end of changes of 'libspice-server.so.1.10.1'===============
    
    Comparing the ABI of binaries between spice-server-0.12.8-1.fc23.x86_64.rpm and spice-server-0.13.3-2.fc25.x86_64.rpm:
    
    ================ changes of 'libspice-server.so.1.10.1'===============
     Functions changes summary: 0 Removed, 0 Changed (85 filtered out), 3 Added functions
     Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
    
    3 Added functions:
    
    'function void spice_qxl_gl_draw_async(QXLInstance*, uint32_t, uint32_t, uint32_t, uint32_t, uint64_t)' {spice_qxl_gl_draw_async@@SPICE_SERVER_0.13.1}
     'function void spice_qxl_gl_scanout(QXLInstance*, int, uint32_t, uint32_t, uint32_t, uint32_t, int)' {spice_qxl_gl_scanout@@SPICE_SERVER_0.13.1}
     'function int spice_server_set_video_codecs(SpiceServer*, const char*)' {spice_server_set_video_codecs@@SPICE_SERVER_0.13.2}
    
    ================ end of changes of 'libspice-server.so.1.10.1'===============
    
    $

    As you can see in the report above, the name of the spice-server package in Fedora 23 is actually spice-server-0.12.8-1.fc23. In Fedora 25, the package is spice-server-0.13.3-2.fc25.

    These packages are available for 3 architectures: i686, x86_64 and armv7hl.

    There is one shared library library in the spice-server package which has ABI changes; it's libspice-server.so.1.10.1.

    We see that the ABI changes are all the same for all the 3 architectures. So we can just focus on one of the architectures. Let's look at the ARM architecture then.

    The summary of the changes says:

    Comparing the ABI of binaries between spice-server-0.12.8-1.fc23.armv7hl.rpm and spice-server-0.13.3-2.fc25.armv7hl.rpm:
    
    ================ changes of 'libspice-server.so.1.10.1'===============
     Functions changes summary: 0 Removed, 0 Changed (85 filtered out), 3 Added functions
     Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

     

    In other words, 3 functions were added to the Fedora 25 version of the libspice-server.so.1.10.1 shared library.

    An interesting piece of information from that report is this one:

    Functions changes summary: [...] 0 Changed (85 filtered out) [...].

     

    This means some types used by the signature of 85 functions exported by the shared library changed. But the tool figured out that the changes are to be filtered out because they are harmless. There are ways to see and analyze these changes nevertheless. More on this in a subsequent blog post. For now, we shall rejoice that we have 85 less functions to analyze :-)

    So let's focus on the other changes that the tool is reporting:

    3 Added functions:
    
    'function void spice_qxl_gl_draw_async(QXLInstance*, uint32_t, uint32_t, uint32_t, uint32_t, uint64_t)' {spice_qxl_gl_draw_async@@SPICE_SERVER_0.13.1}
     'function void spice_qxl_gl_scanout(QXLInstance*, int, uint32_t, uint32_t, uint32_t, uint32_t, int)' {spice_qxl_gl_scanout@@SPICE_SERVER_0.13.1}
     'function int spice_server_set_video_codecs(SpiceServer*, const char*)' {spice_server_set_video_codecs@@SPICE_SERVER_0.13.2}

     

    In the report above we see that 3 new functions were added:

    spice_qxl_gl_draw_async
    spice_qxl_gl_scanout
    spice_server_set_video_codecs

     

    The ELF symbol of these functions are shown in curly brackets in the report:

    spice_qxl_gl_draw_async@@SPICE_SERVER_0.13.1
    spice_qxl_gl_scanout@@SPICE_SERVER_0.13.1
    spice_server_set_video_codecs@@SPICE_SERVER_0.13.2

     

    We see that maintainers of the spice-server library carefully version the ELF symbols of these newly added functions and that the version of these new functions is the string 'SPICE_SERVER_0.13.1'.

    Beyond Fedora

    Interested readers might have figured out that anyone can install the Koji build system software to build her own RPMs. There actually are many examples of Koji systems being used all over the internet.

    So users can tell fedabipkgdiff to use any Koji instance of their choice, not necessarily the one running at https://koji.fedoraproject.org.

    To do so, they can use the --server option of fedabipkgdiff to point to their Koji installation of choice.

    For other build systems of other distributions, I hope this article shows that it's possible to write an equivalent tool tailored for their needs, reusing the foundations laid out with the Libabigail framework.

    Getting fedabipkgdiff

    On Fedora, at least 23, please type:

    dnf install libabigail

     

    On RHEL, CentOS 6 or 7, with the EPEL repository configured, please type:

    yum install libabigail

     

    And you should be all set.

    Credits

    I would like to thank Chenxiong Qi who actually wrote the fedabipkgdiff tool on his own free time. He demonstrated the feasibility of using Libabigail and its associated tools to write ABI change analysis systems tailored, in this case, for a particular software distribution.

    Last updated: February 24, 2024

    Recent Posts

    • A day in the life of an NVIDIA H100 on Red Hat OpenShift 5

    • Migrate BuildConfigs to builds for Red Hat OpenShift with one plug-in install

    • Run Red Hat Enterprise Linux CoreOS on NVIDIA BlueField DPUs

    • Agent harness engineering: Separating model capabilities from enforcement

    • What's new for developers in Red Hat Enterprise Linux 10.3 and 9.9

    Red Hat Developers logo

    Platforms

    • Red Hat AI
    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform
    • See all products

    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
    © 2026 Red Hat

    Red Hat legal and privacy links

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