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" ?

-- 
Andrew C. Aitchison					Kendal, UK
 			[log in to unmask]