Undefined symbol when using UFO models

[Benjamin Pachev]

When using Whizard 3.1.4 installed from Spack, I cannot run any external UFO models without encountering the following error: 'whizard: symbol lookup error: ./.libs/default_lib.so.0: undefined symbol: __omega_vectors_MOD_momentum_of_array'

This issue can be worked around by prepending LD_PRELOAD=$WHIZARD_SPACK_ROOT/lib/libomega_core.so to the whizard invocation. Looking through the generated default_lib.makefile, I see -lomega but no -lomega_core. This seems to be a bug, as the symbol '__omega_vectors_MOD_momentum_of_array' is only found in 'libomega_core.so', not 'libomega.so'.

Steps to reproduce:

wget https://whizard.hepforge.org/models/dim6top_LO_UFO_mod.tar.gz
tar xf dim6top_LO_UFO_mod.tar.gz

whizard test.sin

where test.sin has the following contents:

model=dim6top_LO_UFO (ufo)
show (model)
beams = "e-", "e+"
process bornproc = "e-", "e+" => "W+","b","W-","b~"
sqrts = 400 GeV
n_events=10000
sample_format = lhef
simulate (bornproc)

The output of whizard --build-config is:
WHIZARD 3.1.4
Build configuration:
  precision 15 (significant decimals of real/complex numbers)
Optional features available in this build:
  OpenMP yes (OpenMP parallel execution)
  GoSam no (external NLO matrix element provider)
  OpenLoops no (external NLO matrix element provider)
  Recola no (external NLO matrix element provider)
  LHAPDF no (PDF library)
  HOPPET no (PDF evolution package)
  fastjet yes (jet-clustering package)
  Pythia6 yes (direct access for shower/hadronization)
  Pythia8 no (direct access for shower/hadronization)
  StdHEP yes (event I/O format)
  HepMC yes (event I/O format)
  LCIO yes (event I/O format)
  MetaPost no (graphical event analysis via LaTeX/MetaPost)

This issue occurs with every external UFO model I tried, and the LD_PRELOAD workaround works for all of them so far.

[Juergen Reuter (j.r.reuter)]

Hi Benjamin, thanks for reporting this.
We never encountered such an issue before. Apparently, compiling the matrix element code and linking it into default_lib.so had worked. When I do the same and look at the linked libraries (also using a Ubuntu 24.04 LTS), I get:
$ ldd .libs/default_lib.so.0.0.0
 linux-vdso.so.1 (0x00007fff48567000)
 libomega_core.so.0 => /nfs/theoc/data1/reuter/local/lib/libomega_core.so.0 (0x0000767e239d0000)
 libwhizard.so.2 => /nfs/theoc/data1/reuter/local/lib/libwhizard.so.2 (0x0000767e1f569000)
 libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5 (0x0000767e1f200000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000767e1f117000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000767e1ee00000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000767e1f0e9000)
 libvamp.so.0 => /nfs/theoc/data1/reuter/local/lib/libvamp.so.0 (0x0000767e1f094000)
 libcirce1.so.0 => /nfs/theoc/data1/reuter/local/lib/libcirce1.so.0 (0x0000767e1f52c000)
 libcirce2.so.0 => /nfs/theoc/data1/reuter/local/lib/libcirce2.so.0 (0x0000767e1f520000)
 libLHAPDF.so => /nfs/theoc/data1/reuter/local/lib/libLHAPDF.so (0x0000767e1ed03000)
 [...]

So there the linker can resolve the dynamic library libomega_core.so.0. Could it be that this installation directory is not in your LD_LIBRARY_PATH? On the other hand, it is strange that the libwhizard had been found. If you want you could sent us the config.log from your Whizard build, preferrably via email (as it contains system information), < whizard [at] desy.de)

Best,
   JRR (Juergen)

[Benjamin Pachev (bpachev)]

Hi Juergen.
  Thanks for your prompt response. The issue isn't with LD_LIBRARY_PATH - the issue is that the compilation doesn't even try to link against libomega_core. When I run ldd on .libs/default_lib.so.0.0.0 I don't see libomega_core as in your listing, just libwhizard. Looking at the generated Makefile (default_lib.makefile), I see -lomega, but not -lomega_core.
  I installed the package through Spack, so I don't have the configure.log at hand, but will rebuild and share the configure.log via email. The command used to install Whizard via Spack was
   "spack install whizard@3.1.4+fastjet~gosam~latex+lcio+lhapdf~openloops+openmp~pythia8"

All the best,

Benjamin.

[Benjamin Pachev (bpachev)]

My apologies - the actual command was 'spack install whizard@3.1.4+fastjet+lcio+lhapdf+openmp~pythia8'

[Juergen Reuter (j.r.reuter)]

Hi Benjamin,
a few remarks here: this should not at all be connected to UFO models, the problem should appear also for the in-house models of Whizard. The link procedure is the same. Something you could check out. Secondly, libomega_core should be included in libomega via libtools, that it is not found looks like a bug in autotools or libtool:
libomega_la_LIBADD = \
  ../omega/src/libomega_core.la \
  models/libmodels.la
Thirdly, as you get Whizard from Spack, this could be more an issue of the Spack build. Could you please contact the Spack team to find out how this has been built.
Cheers,
    JRR (Juergen)

[Juergen Reuter (j.r.reuter)]

One more question, as you built via spack, do you still have the log files from the spack build?
They should be in <prefix>/.spack as a file like spack-build-out.txt.gz .
Maybe you can send this to us via email?