Building 32-bit ROOT on Linux EL9

Hello ROOT community,

I’m attempting to build 32-bit ROOT 6.28.02 from scratch on AlmaLinux 9.1 x86_64. I was able to successfully build the 64-bit version, but am having a bit of difficulty building a 32-bit version.

In my first attempt at a 32-bit build, I simply did a “setarch i386” before configuring the build directory. I (eventually) got this to build, but ended up with a mixed bag of 32 and (mostly) 64 bit objects.

I then attempted to add 32-bit compile flags to the build config:

  1. setarch i386
  2. cmake -DCMAKE_C_FLAGS=“-m32” -DCMAKE_CXX_FLAGS=“-m32” …

With these flags, the build node would not even configure correctly; I receive the below error, even though these headers/libraries are present.

CMake Error at cmake/modules/SearchInstalledSoftware.cmake:390 (message):
libXft and Xft headers must be installed.
Call Stack (most recent call first):
CMakeLists.txt:254 (include)

So, my questions are:

  • Is cross-building a 32-bit version of ROOT 6.28.02 supported?

  • If cross-building is supported, what’s the correct approach?

Thanks for any assistance,

Larry Mills

P.S. After reading more carefully, I see that v 6.24 is the last version that should be compiled with gcc 11, so I tried the same 32-bit build approach on version 6.24.08, with the same resulting build error that I encountered with 6.28.02.

_ROOT Version: 6.28.02, 6.24.08
_Platform: AlmaLinux 9.1 x86_64
_Compiler: gcc 11.3.1

Welcome to the ROOT forum.

I am not sure what could be the problem. Maybe @bellenot has an idea?

Did you install libXft-devel, as the error message is telling? See also Dependencies - ROOT

Thanks for the responses - but yes, checking the package dependencies was the first thing I looked at.

Installed Packages
libXft.i686                            2.3.3-8.el9                    @AppStream
libXft.x86_64                          2.3.3-8.el9                    @AppStream
libXft-devel.i686                      2.3.3-8.el9                    @AppStream
libXft-devel.x86_64                    2.3.3-8.el9                    @AppStream

Even if I set “-Dx11=OFF” (which I really need) the next error I quickly encounter is in building LZMA:

$ cmake -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32 -Dxrootd=OFF -Dx11=OFF -DCMAKE_INSTALL_PREFIX=../install ../root-6.24.08

[  0%] Performing build step for 'LZMA'
CMake Error at /scratch/lgmills/root/build/LZMA-prefix/src/LZMA-stamp/LZMA-build-.cmake:49 (message):
  Command failed: 2


The “LZMA-build-err.log” contains:

check/crc32_x86.S: Assembler messages:
check/crc32_x86.S:96: Error: invalid instruction suffix for `push'
check/crc32_x86.S:97: Error: invalid instruction suffix for `push'
check/crc32_x86.S:98: Error: invalid instruction suffix for `push'
check/crc32_x86.S:99: Error: invalid instruction suffix for `push'
check/crc32_x86.S:132: Error: relocated field and relocation type differ in signedness
check/crc32_x86.S:265: Error: invalid instruction suffix for `pop'
check/crc32_x86.S:266: Error: invalid instruction suffix for `pop'
check/crc32_x86.S:267: Error: invalid instruction suffix for `pop'
check/crc32_x86.S:268: Error: invalid instruction suffix for `pop'
gmake[7]: *** [Makefile:939: liblzma_la-crc32_x86.lo] Error 1
gmake[6]: *** [Makefile:1553: all-recursive] Error 1
gmake[5]: *** [Makefile:420: all-recursive] Error 1
gmake[4]: *** [Makefile:613: all-recursive] Error 1
gmake[3]: *** [Makefile:480: all] Error 2

Well, I can’t really help here. But my question is why do you want a 32 bit build? And maybe @Axel has an idea about what could be wrong.

I understand that building anything 32-bit nowadays is considered a fringe use case, but unfortunately we have a large legacy code base that is all 32-bit and still needs to be supported for years to come.

I even tried building gcc 8 and building v5.34.38 with it, but that effort failed too.

At this point, I’m afraid we’re going to be forced to abandon our ROOT-based apps on EL9.

Don’t worry, we’ll find a solution, it will just take some time…

So bad news: building 32 bit ROOT on 64 bit Linux is not supported anymore. If you need 32 bit build of ROOT you will need a 32 bit machine… Maybe @Axel can give more details about this


Sorry for not conveying this correctly to Bertrand: we do support 32bit builds, and while we prefer to actually build and test on native 32 bit operating systems it should still be possible to cross-build - given that the distro actually still offers this option, which is not something we follow or validate.

What you report seems to suggest that we do not pass -m32 to some of the packages (LZMA in this case) we build ourselves; that’s something we ought to fix.

CMake not finding the 32bit headers is something I don’t know how to solve (I bet it’s not realizing you want a 32 bit build); @amadio do you have a hint of how we might get that solved? I only found c++ - The proper way of forcing a 32-bit compile using CMake - Stack Overflow - maybe that helps?

That said: I was convinced that we are testing our 32bit builds in vain. For my education, what forces you to continue to provide 32bit builds?

1 Like

Thanks @bellenot and @Axel. Well, it sounds like I may not be totally out of luck, but as I suspected, I might be the first or only attempt at a 32-bit cross-build in recent memory. I’ll give the “CMake Toolchain” approach a try, although as the seemingly most important part of that approach is passing the “-m32” flags, I’m not very optimistic at my odds of success.

As for the need for 32-bit - much of Fermilab’s experiment control software architecture remains 32-bit even though it runs almost entirely in a x86_64 environment. This software is being evolved (slowly), but the substantial 32-bit base will likely remain in use for another decade - or longer.

Maybe you could create and use a 32-bit Apptainer/Singularity container.

I attempted the cmake toolchain file approach suggested in the post referenced in @Axel reply. Alas, I get the same cmake error while creating the build node as I did before - that is, it can’t find the installed Xft 32-bit library.

-- X11_Xpm_INCLUDE_PATH: /usr/include
-- X11_Xpm_LIB: /usr/lib/
CMake Error at cmake/modules/SearchInstalledSoftware.cmake:353 (message):
  libXft and Xft headers must be installed.
Call Stack (most recent call first):
  CMakeLists.txt:219 (include)

Toolchain file contents:

# which compilers to use for C and C++
set(CMAKE_C_FLAGS -m32)

# here is the target environment located
set(CMAKE_FIND_ROOT_PATH  /usr/lib /usr/include )

# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment

@Wile_E_Coyote - that’s a creative approach, and if my local users that need ROOT going forward want to pursue it, more power to 'em. Thanks everyone for the suggestions, but for the time being, it looks my users will be going ROOT-less.

You’ll probably need


Does that help? I’d expect that you might still be hit by the error in Performing build step for 'LZMA'. If so I will try to solve it - let me know!

I lied a little in my previous response… I still receive the “missing Xft” error if I do not set the CMAKE_FIND_ROOT_PATH" parameter in the toolchain file (all other settings are as I listed though).

If I do set the “CMAKE_FIND_ROOT_PATH” as I indicated before (i.e. /usr/lib /usr/include), I get a different X11 detection error. Adding the additional parameters in your reply made no difference in either case.

Here’s the error when CMAKE_FIND_ROOT_PATH is set as I stated:

-- Looking for xxHash
-- Could NOT find xxHash (missing: xxHash_LIBRARY xxHash_INCLUDE_DIR)
-- xxHash not found. Switching on builtin_xxhash option
-- Looking for LZ4
-- Could NOT find LZ4 (missing: LZ4_LIBRARY LZ4_INCLUDE_DIR)
-- LZ4 not found. Switching on builtin_lz4 option
-- Looking for X11
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 
  Could NOT find X11 (missing: X11_X11_INCLUDE_PATH X11_X11_LIB)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILU
  /usr/share/cmake/Modules/FindX11.cmake:457 (find_package_handle_standard_args)
  cmake/modules/SearchInstalledSoftware.cmake:16 (_find_package)
  cmake/modules/SearchInstalledSoftware.cmake:329 (find_package)
  CMakeLists.txt:219 (include)

If you drop ROOT and want to have a well-supported binary data format, try: HDF5

At Fermilab … ask DUNE people.

A late update on this thread - after searching the forum a bit more with regard to old builds, I found that I was able to successfully build the last “unofficial” v5 root release, v5-34-00-patches as 32-bit. This version built on both CentOS Stream 8 and AlmaLinux 9.2. On AlmaLinux 9.2 the build had to be configured with “–disable-memstat” due to a deprecation issue with malloc hooks in that release’s version of glibc.

The only thing I had to do to force a 32-bit build was to execute “setarch i386” before performing the configure and make commands.

So, for now, I’m set. It would be nice to be able to build a v6 release as 32-bit, but as the legacy codebase I’m working with still uses v5, this should work fine.

You can use Fedora. dnf -y install root.i686 will give you 32-bit version. Modulo you perhaps should veto 64-bit version.

Thanks for the suggestion; if we ever move to ROOT 6, I may give that approach a try.