xdg-open doesn't work

[dudarboh]

@tmadlener

Issue

As title says, xdg-open doesn't work in the current key4hep:

$ source /cvmfs/ilc.desy.de/key4hep/setup.sh
$ xdg-open funny_dog_image.png
START /usr/bin/gwenview "/path/to/funny_dog_image.png" -caption "%c" %i
/usr/bin/gwenview: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /cvmfs/ilc.desy.de/key4hep/spackages/mesa/21.3.1/x86_64-centos7-gcc11.2.0-opt/iwtk4bgnt5vlgo5himatc2k2kmph6xb4/lib/libGL.so.1)
/usr/bin/gwenview: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /cvmfs/ilc.desy.de/key4hep/spackages/mesa/21.3.1/x86_64-centos7-gcc11.2.0-opt/iwtk4bgnt5vlgo5himatc2k2kmph6xb4/lib/libGL.so.1)
/usr/bin/gwenview: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /cvmfs/ilc.desy.de/key4hep/spackages/mesa/21.3.1/x86_64-centos7-gcc11.2.0-opt/iwtk4bgnt5vlgo5himatc2k2kmph6xb4/lib/libGL.so.1)
/usr/bin/xdg-open: line 658: 13668 Segmentation fault      $browser "$1" > /dev/null 2> /dev/null
xdg-open: no method available for opening '/path/to/funny_dog_image.png'

following the pop-up error from the "Konqueror":

Although this command work fine in the latest iLCSoft environment:

$ source /cvmfs/ilc.desy.de/sw/x86_64_gcc82_centos7/v02-02-03/init_ilcsoft.sh
$ xdg-open funny_dog_image.png
(image is opened in a "Gwenview")

Workaround

$ display funny_dog_image.png works as an alternative fine in both iLCSoft and key4hep using "ImageMagick" to open an image

[mirguest]

It seems the gcc's lib64 is not available in the $LD_LIBRARY_PATH. A temporary solution is add gcc's lib64 explictly:

export LD_LIBRARY_PATH=/cvmfs/ilc.desy.de/key4hep/spackages/gcc/11.2.0/x86_64-centos7-gcc4.8.5-opt/7isdlpuoi7cbcsugpa2hzuqhh5zgeapj/lib64:$LD_LIBRARY_PATH

[tmadlener]

@vvolkl do we need to put the compiler on LD_LIBRARY_PATH in the setup script?

[vvolkl]

I cannot reproduce this with the latest release in sw.hsf.org, so I don't know if that is really required (but it wouldn't hurt)

[mirguest]

This issue will only affect some system level libraries, as there is no RPATH. The libraries installed by spack should be already using the correct RPATH, so they don't need to setup LD_LIBRARY_PATH explictly.

[mirguest]

For example:

[lint@lxslc705]$ chrpath /usr/bin/gwenview
/usr/bin/gwenview: no rpath or runpath tag found.
[lint@lxslc705]$ ldd /usr/bin/gwenview
/usr/bin/gwenview: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /cvmfs/ilc.desy.de/key4hep/spackages/mesa/21.3.1/x86_64-centos7-gcc11.2.0-opt/iwtk4bgnt5vlgo5himatc2k2kmph6xb4/lib/libGL.so.1)
/usr/bin/gwenview: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /cvmfs/ilc.desy.de/key4hep/spackages/mesa/21.3.1/x86_64-centos7-gcc11.2.0-opt/iwtk4bgnt5vlgo5himatc2k2kmph6xb4/lib/libGL.so.1)
/usr/bin/gwenview: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /cvmfs/ilc.desy.de/key4hep/spackages/mesa/21.3.1/x86_64-centos7-gcc11.2.0-opt/iwtk4bgnt5vlgo5himatc2k2kmph6xb4/lib/libGL.so.1)

[tmadlener]

As Tao said, I think this is more a problem of NAF vs. lxplus. Respectively, the differences in software that are available outside of key4hep and to which xdg-open will delegate. Unfortunately, sw.hsf.org is not mounted on DESY NAF machines, so I can't easily test what happens there and if this is really just a case of the installation on ilc.desy.de or a NAF "feature".

Alternatively we might consider adding a few packages that can be used to view images to the stack (or do we already have those and it is just xdg-open that doesn't delegate to the right one?)

[mirguest]

I had similar issues at IHEP before. My solultion is using env -i to start a clean environment, for example:

[lint@lxslc705]$ env -i gwenview

[vvolkl]

Maybe the better solution is to avoid using the LD_LIBRARY_PATH alltogether. Using RPATHs means it should not be necessary and would allow system packages to just use system libraries. Spack itself does not set it anymore, and it should only be needed for packages providing ROOT dictionaries or Gaudi/DD4hep plugins. I already tried to do this by only adding packages depending on ROOT and am not sure why the opengl libraries are in the LD_LIBRARY_PATH in the first place. Could be that there is a bug and ROOT dependencies have been added as well.

[tmadlener]

Depending on when you made those changes, the installation with the reported issue might not be using the updated setup script generation yet.

[vvolkl]

The LD_LIBRARY_PATH is populated also for the recent 2022-04-22 release, it seems that it's rather that I overlooked that spack still sets LD_LIBRARY_PATH on linux. I've just published a key4hep release without a general LD_LIBRARY_PATH (by doing:

https://github.com/key4hep/spack/commit/5beda4cf4a0c5a1cd7806f2de4f6e3c8f1c8225f

) to check if that makes problem elsewhere, but it should fix the issue.

[jmcarcell]

With the latest nightly this works for me, although it used Okular to open an image which is not great, probably by configuring it images can be seen with another program. Closing...