SCIENTIFIC-LINUX-USERS Archives

October 2021

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Götz Waschk <[log in to unmask]>
Reply To:
Götz Waschk <[log in to unmask]>
Date:
Thu, 28 Oct 2021 19:45:24 +0200
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (3538 bytes) , smime.p7s (5 kB)
Am 28.10.21 um 18:09 schrieb Andrew C Aitchison:
> 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 <[log in to unmask] 
>>> <mailto:[log in to unmask]>> wrote:
>>>
>>>     Am 26.10.21 um 04:27 schrieb Patrick J. LoPresti:
>>>      > On Mon, Oct 25, 2021 at 5:45 PM Nico Kadel-Garcia
>>>     <[log in to unmask] <mailto:[log in to unmask]>
>>>      > <mailto:[log in to unmask] <mailto:[log in to unmask]>>> 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" ?

Dear Andrew,
while it is possible to bind-mount libraries into a singularity 
container, this didn't happen here.

To proof that it depends on the kernel, I have installed the Oracle UEK 
kernel on my test machine:

# uname -r
5.4.17-2136.300.7.el7uek.x86_64
# cat /etc/redhat-release
Scientific Linux release 7.9 (Nitrogen)
# singularity exec U20.img gnuplot-qt

         G N U P L O T
         Version 5.2 patchlevel 8    last modified 2019-12-01

         Copyright (C) 1986-1993, 1998, 2004, 2007-2019
         Thomas Williams, Colin Kelley and many others

         gnuplot home:     http://www.gnuplot.info
         faq, bugs, etc:   type "help FAQ"
         immediate help:   type "help"  (plot window: hit 'h')

Terminal type is now 'qt'
gnuplot>

So somehow the dynamic linker of Ubuntu 20.04 has a kernel dependency 
that isn't satisfied by good old 3.10.0-1160.
-- 
Götz Waschk                            ° Phone:  +49 33762 77169
Deutsches Elektronen-Synchrotron DESY  ° E-Mail: [log in to unmask]
Platanenallee 6
15738 Zeuthen Germany



ATOM RSS1 RSS2