Aborting with "std::align_val_t is not implemented yet", RHEL 9.2

ROOT Version: 6.28/04
Platform: RockyLinux 9.2 (RHEL 9.2)
Compiler: gcc 11.3.1

Hi, I have been compiling/porting our app onto newer versions of linux, with the latest version of root. I have been using dnf to install root and the different packages associated with it. I was successful to do it with RockyLinux 8.8 and compilation succeeds also with RockyLinux 9.2. But I’m having a problem when trying to run a root GUI in RockyLinux 9.2 but in RockyLinux 8.8 it works fine. The problem starts with instantiating the root application:

        // **************************************************************************
        // * ROOT SETUP
        // **************************************************************************

        TApplication theApp("App",NULL, NULL);

Below is the trace that I get when I try to run this:

[vmecomp@cerebro1 SuperCytDaemon]$ doView
doView[1272618]: Client Started
Fatal in <operator new>: with std::align_val_t is not implemented yet
#0  0x00007f04d571829a in wait4 () from /lib64/libc.so.6
#1  0x00007f04d566195b in do_system () from /lib64/libc.so.6
#2  0x00007f04d75081b4 in TUnixSystem::StackTrace() () from /usr/lib64/root/libCore.so.6.28
#3  0x00007f04d73d5cb1 in DefaultErrorHandler(int, bool, char const*, char const*) () from /usr/lib64/root/libCore.so.6.28
#4  0x00007f04d7491d26 in ErrorHandler () from /usr/lib64/root/libCore.so.6.28
#5  0x00007f04d7492609 in Fatal(char const*, char const*, ...) () from /usr/lib64/root/libCore.so.6.28
#6  0x00007f04d81af85d in operator new(unsigned long, std::align_val_t) () from /usr/lib64/root/libNew.so.6.28
#7  0x00007f04d226b620 in std::pair<llvm::StringMapIterator<llvm::cl::Option*>, bool> llvm::StringMap<llvm::cl::Option*, llvm::MallocAllocator>::try_emplace<llvm::cl::Option*>(llvm::StringRef, llvm::cl::Option*&&) () from /usr/lib64/root/libCling.so
#8  0x00007f04d226b9e1 in (anonymous namespace)::CommandLineParser::addOption(llvm::cl::Option*, llvm::cl::SubCommand*) () from /usr/lib64/root/libCling.so
#9  0x00007f04d226beca in llvm::cl::Option::addArgument() () from /usr/lib64/root/libCling.so
#10 0x00007f04cef15817 in __static_initialization_and_destruction_0(int, int) [clone .constprop.0] () from /usr/lib64/root/libCling.so
#11 0x00007f04d82201ae in call_init (env=0x7ffee5f01f98, argv=0x7ffee5f01f88, argc=1, l=<optimized out>) at dl-init.c:70
#12 call_init (l=<optimized out>, argc=1, argv=0x7ffee5f01f88, env=0x7ffee5f01f98) at dl-init.c:26
#13 0x00007f04d822029c in _dl_init (main_map=0xa1c050, argc=1, argv=0x7ffee5f01f88, env=0x7ffee5f01f98) at dl-init.c:117
#14 0x00007f04d5795f65 in _dl_catch_exception () from /lib64/libc.so.6
#15 0x00007f04d8226cbe in dl_open_worker (a=0x7ffee5f01530) at dl-open.c:803
#16 0x00007f04d5795f08 in _dl_catch_exception () from /lib64/libc.so.6
#17 0x00007f04d822704f in _dl_open (file=<optimized out>, mode=-2147483647, caller_dlopen=0x7f04d73a592f <TROOT::InitInterpreter()+703>, nsid=-2, argc=1, argv=0x7ffee5f01f88, env=0x7ffee5f01f98) at dl-open.c:879
#18 0x00007f04d569b86c in dlopen_doit () from /lib64/libc.so.6
#19 0x00007f04d5795f08 in _dl_catch_exception () from /lib64/libc.so.6
#20 0x00007f04d5795fd3 in _dl_catch_error () from /lib64/libc.so.6
#21 0x00007f04d569b33e in _dlerror_run () from /lib64/libc.so.6
#22 0x00007f04d569b921 in dlopen
GLIBC_2.2.5 () from /lib64/libc.so.6
#23 0x00007f04d73a592f in TROOT::InitInterpreter() () from /usr/lib64/root/libCore.so.6.28
#24 0x00007f04d73a5aff in ROOT::Internal::GetROOT2() () from /usr/lib64/root/libCore.so.6.28
#25 0x00007f04d73b25b5 in TApplication::TApplication(char const*, int*, char**, void*, int) () from /usr/lib64/root/libCore.so.6.28
#26 0x00000000004213f5 in main (argc=1, argv=0x7ffee5f01f88) at doView.cpp:190
Aborted (core dumped)

Do you have an idea of how I can go over this? I’ve tried to force app compilation to use c++17, to no effect. Do I need to uninstall root and do a root build myself?

Many thanks in advance,


I don’t know which versions of gcc are on RockyLinux 8.8. and 9.2, but you should make sure they matche the compiler used to build ROOT, other than that, maybe @Axel has other suggestions

Please don’t link against libNew. Is that an option for you?

I tried that, but somehow it didn’t work. I used root-config --nonew for that.

Rocky 8.8 uses GCC 8.5.0 (RedHat 8.5.0-14)
Rocky 9.2 uses GCC 11.3.1 (RedHat 11.3.1-4)

Is there a way that I can know what compiler was used for the epel version of root6?

You can check your version of ROOT at startup. For example:

ubuntu@root-cmake-devel:~$ root
  | Welcome to ROOT 6.29/01                        https://root.cern |
  | (c) 1995-2022, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Aug 09 2023, 12:57:56                 |
  | From heads/master@v6-29-01-2306-g9b93dbb7d2                      |
  | With c++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0                   |
  | Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q'  |

Is that good enough?

Thanks, I get

vmecomp@cerebro1 SuperCytDaemon]$ root
  | Welcome to ROOT 6.28/04                        https://root.cern |
  | (c) 1995-2022, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on May 08 2023, 02:44:07                 |
  | From tags/v6-28-04@v6-28-04                                      |
  | With g++ (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4)                |
  | Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q'  |

So it looks like it matches Rocky 9.2…

can you share a minimal reproducer and how you configure/build it?

let me work on that

Unfortunately I have to concede noobie mistake. In following @Alex’s suggestion I had added the --nonew switch to the compilation, but when I was executing the program it was running from the installed location, not the built location ( host> doView, instead of host> ./doView). So I didn’t have to change anything besides taking out the -lNew library. The question now is, why would it fail with the -lNew switch, and when is -lNew required? The other thing I noticed (somewhat unrelated) is that the .pcm files generated with the dictionary seem to be necessary at runtime and should be in the path otherwise the app runs but claims an error. What are the best practices for installation of these files?

What are the best practices for installation of these files?

They must be copied along side the library that contains the dictionary.

The question now is, why would it fail with the -lNew switch,

As the message hints, we have not yet implemented in libNew the required overload of operator new.

and when is -lNew required?

It is needed if and only if you are need to use “shared memory” to pass information between 2 processes (i.e. you are very unlikely to need it).

As luck had it, we do use shared memory for inter-process communication in a couple of situations. Hmm.

Yes BUT do you use TMapFile as part of this infrastructure? (If not, you still don’t need it).

Unfortunately we do…

Then the easiest is probably to implement it. See https://github.com/root-project/root/blob/befd36fdb131984373f3fad63e4f8de44b7c3ded/core/newdelete/src/NewDelete.cxx#L205 and surrounding implementations.

The code of an existing implementation (above for example) needs to be copy/paste and adjusted to respect the requested alignment.

Could you give it a try and open a PR?

ooh that’s a bit above my pay grade… here we’re trying to move away from tinkering with the root sources, and you’re asking me to do that? :slight_smile:

What can I say, it is a lot of fun ? :smiley: :smiley: :smiley:

Hmm, I had installed root using dnf. If I understand this well, this would require me to uninstall root, get root from gitlab and do a full build and install from there, right?

I found this article that may help in the implementation: