On Thu, 28 Oct 2021, Götz Waschk wrote:
Am 28.10.21 um 15:41 schrieb Troy Dawson:
On Thu, Oct 28, 2021 at 4:56 AM Götz Waschk <goetz.was...@desy.de
<mailto:goetz.was...@desy.de>> wrote:
Am 26.10.21 um 04:27 schrieb Patrick J. LoPresti:
> On Mon, Oct 25, 2021 at 5:45 PM Nico Kadel-Garcia
<nka...@gmail.com <mailto:nka...@gmail.com>
> <mailto:nka...@gmail.com <mailto:nka...@gmail.com>>> wrote:
> >
> > It's getting harder.
>
> Singularity containers for CentOS 8 (and latest Ubuntu etc.) work
fine
> on SL7, for now. Of course this is not a long-term solution, since
> "kernel too old" will surely crop up eventually.
I just like to add that this has already happened to me with an Ubuntu
20.04 LTS container running on
SL7:
[wgs34:U20] ~ % gnuplot-qt
gnuplot-qt: error while loading shared libraries: libQt5Core.so.5:
cannot open shared object file: No such file or directory
... snip ...
That doesn't have much to do with the container running on SL7, and more
that your gnuplot-qt was compiled on a different qt5 than is in the
container.
Without more details I couldn't exactly say more than make sure your
gnuplot-qt and qt5 libraries in yoru container are up to date.
Hi Troy,
it is related to the SL7 kernel. The container contains a standard Ubuntu
20.04 LTS installation with the default gnuplot package. The problem
disappears when I run the same singularity container on AlmaLinux 8.4 or
Ubuntu 18.04 LTS.
The practice of containers seems to be to make them fast and lightweight
by using host libraries as much as possible, which is not compatible with
portability.
This problem is not caused by what I would call "the SL7 kernel".
Have containers hijacked the word "kernel" to mean something like
"the assumed base system including common libraries" ?
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
