Undefined reference to `tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long)’

I’m installing Delphes inside Madgraph. And the following error occurs:
/usr/bin/ld: /snap/root - framework/753/usr/local/lib/libImt.so: undefined reference to `tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long)’]
collect2: error: ld returned 1 exit status
make: *** [Makefile: 2579: hepmc2pileup] Error 1


First of all, welcome to the ROOT forum!

Could you elaborate a bit more on what you are doing? According to the error, the linker is not able to resolve a symbol provided by libtbb.so (required from libImt.so). Could you provide the output of

$ ldd '/snap/root - framework/753/usr/local/lib/libImt.so' | grep libtbb

To me it seems like it might be trying to link against a different version of libtbb.so which might be provided by your system (as opposed to using one provided in the Snap package). In that case, including the correct path in the library search path might fix it.


Hi J! Thanks a lot for your rapid reply!

I’m using the Madgraph (event generator) on Ununtu 22.04 and try to install Delphes with command: MG5_aMC>install Delphes. Then the Madgraph should install Delphes by itself. During this process, I encountered the error:
/usr/bin/ld: /snap/root - framework/753/usr/local/lib/libImt.so: undefined reference to `tbb::interface7::internal::isolate_within_arena(tbb::interface7::internal::delegate_base&, long)’]
collect2: error: ld returned 1 exit status
make: *** [Makefile: 2579: hepmc2pileup] Error 1

The output of $ ldd ‘/snap/root-framework/753/usr/local/lib/libImt.so’ | grep libtbb is:
libtbb.so.2 => /lib/x86_64-linux-gnu/libtbb.so.2 (0x00007f61c5600000)

Great appreciation!



Yes, it seems that it’s using a different version of libtbb.so provided by the system instead of what is provided in the Snap package. This issue might be of interest to @James-Carroll.

You could try the following before installing Delphes

$ export LD_LIBRARY_PATH="/snap/root-framework/753/usr/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH"

and confirm that the dynamic linker is now picking the library from /snap/root-framework/753/usr/lib/x86_64-linux-gnu/, i.e.

$ ldd ‘/snap/root-framework/753/usr/local/lib/libImt.so’ | grep libtbb is:
libtbb.so.2 => /snap/root-framework/753/usr/lib/x86_64-linux-gnu/libtbb.so.2



The ROOT snap isn’t a good candidate for building other native packages from; the files in the bundle are all built (currently) for Ubuntu 20.04 rather than Ubuntu 22.04, and so wouldn’t be expected to be ABI compatible unless they were running in their normal container environment. This also means that there’s no scripts provided similar to thisRoot.sh that would set-up variables like LD_LIBRARY_PATH above, because that doesn’t really make sense for this delivery format as ABI and file paths can change at any time.

The simplest solution would be to prefer the pre-compiled binary releases, or the Conda release, for this situation. As far as snaps go, the answer would be that Madgraph would need to be released as it’s own snap, where it can then always be paired with its own compatible version of ROOT & other libraries.

I’m not familiar with Madgraph, but I’ll take a look this weekend to see if it’s a suitable fit. If so, then it wouldn’t need ROOT (snap or otherwise) as a dependency and would be it’s own independant package, but you’d still be able to install ROOT (snap or otherwise) side by side for analysis on the output, without the two interfering or really knowing the other existed.

Hello again,

Having taken a look at Madgraph; it isn’t suitable for putting into a Snap package by itself; but you can sort of use it with the ROOT snap anyway; it’s not the primary use-case and the support is coincidental rather than something I could actively commit to keep going, but might be good enough for your needs.

I’ve built some new revisions of ROOT with a Fortran compiler built in, which it didn’t have before. Otherwise, the snap does ship the majority of it’s own build environment (e.g GCC and cmake), and so technically can compile other programs/libraries if their dependency graph isn’t too complicated.

Firstly, I’d recommend ensuring you track a specific version branch to make it less likely this will break this in the future, as otherwise the Snap automatically updating could cause problems at an inconvenient time and require you to re-compile. It’s as simple as:

sudo snap refresh --channel v6.26/stable

This will both pull the latest version of package with a Fortran compiler inside it, but also prevent future upgrades to e.g v6.28, which would break ABI compatibility as it would likely rebase on Ubuntu 22.04 rather than Ubuntu 20.04.

Beyond this, the trick is that you need to run the GCC/Fortran compiler inside the container, where $LD_LIBRARY_PATH and etc will also be pointing at the right place. There’s a wrapper script I include in the snap I don’t usually tell people about that helps in this scenario, letting us do this:

cd $HOME
wget https://launchpad.net/mg5amcnlo/3.0/3.4.x/+download/MG5_aMC_v3.4.1.tar.gz
tar xf MG5_aMC_v3.4.1.tar.gz 
sed -i 's/# web_browser = None/web_browser = xdg-open/' MG5_aMC_v3_4_1/input/mg5_configuration.txt
# We do this so Madgraph in the snap can open the correct web browser on the native system, as otherwise the sandbox will interfere
root-framework.run MG5_aMC_v3_4_1/bin/mg5_AMC

In the Madgraph CLI that will open, running inside the container, install Delphes then actually works! And if you continue to invoke Madgraph with root-framework.run, it should be able to find ROOT properly and have a decent chance of successfully running real world use-cases.

As I say, it’s impossible for me to commit to supporting this properly, and you might find that it’s just not viable if you attempt to use it properly. However, it certainly seems to have a decent level of basic functionality that might satisfy your immediate needs, depending on exactly how much you need to get working.

Otherwise, I’d still recommend pre-compiled packages/Conda/etc for a more thorough approach; but in a pinch running MG5 via the snap like above might actually be functional enough for your needs.

(N.B, technically the releases with Fortran aren’t out yet and won’t be on live in the repository until 2-3 hours after this post, as they’re still building in CI as I write this).

Thanks a lot for your detailed reply! This really saved my day!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.