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:
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.
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.
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.
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.
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/libXpm.so
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_COMPILER gcc)
set(CMAKE_C_FLAGS -m32)
set(CMAKE_CXX_COMPILER g++)
set(CMAKE_CXX_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
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
@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.
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
(message):
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
RE_MESSAGE)
/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)
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.