[Feature Request] Cross-platfome single release package

[diyism]

I think that Singularity is far more easy and convenient than docker.

For example I deploy BargeOS img into a digitalocean VPS and then run:

pkg install singularity
singularity build -s debian-test-1/ docker://debian:buster-slim
singularity build -s debian-test-2/ docker://debian:buster-slim
sudo singularity shell --writable debian-test-1/
sudo singularity shell --writable debian-test-2/

It takes me only 2 minutes now I have 2 debian environments in 1 VPS, I think it's "VPS in VPS". and I can zip/backup the debian-test-1 and debian-test-2 directories very conveniently and intuitively compared to docker. (ref: https://gist.github.com/diyism/60aa6ca24df772a4928f1aced65e72ee)

But the singularity version in bargeOS is too old, it's 2.6.0, while the latest singularity version is 3.7.2. So I try to build a latest version of singularity binary in my local debian PC, so that I can upload it to avoid the compiling procedure (time cost and disk space cost in vps) when I deploy many new VPS instances:

ssh root@my_vps_1_ip
apt install ca-certificates
wget https://github.com/OurGI-com/OurGI-src/raw/master/singularity/singularity.zip
unzip singularity.zip
sudo cp singularity /usr/local/bin/singularity
sudo cp singularity.conf  /usr/local/etc/singularity/singularity.conf
sudo cp starter /usr/local/libexec/singularity/bin/starter
mkdir -p /usr/local/var/singularity/mnt/session
echo 'deb http://deb.debian.org/debian buster-backports main contrib non-free' >> /etc/apt/source.list
apt update
apt -t buster-backports install libseccomp2
singularity build -s debian-test-1/ docker://debian:buster-slim
singularity build -s debian-test-2/ docker://debian:buster-slim

ssh root@my_vps_2_ip
apt install ca-certificates
......

ssh root@my_vps_3_ip
apt install ca-certificates
......

But when I deploy other system's VPS, for example, centos, my prebuilt singularity binary will fail to run.

Could we build a cross-platform single package for Singularity? Just like what Justine Tunney have done to redbean webserver and lua interpreter based on "Cosmopolitan libC". (ref: https://github.com/jart/cosmopolitan/issues/140)

[GH-maggio]

I'm new to package building, if the meta-data is added/standardized to the build process in this example, would that work? https://github.com/hpcng/singularity/tree/master/examples/build-singularity

[dtrudg]

Singularity uses relatively low-level code, including CGO code that will link against a system libc and libseccomp. It is not a pure static binary. Generally if you build it on system X it will work on system Y if system Y has a newer glibc. CentOS 7 is, for example, using an older glibc than Debian 10 so a build on Debian 10 will not work on CentOS 7.

$ ldd $(which singularity)
    linux-vdso.so.1 (0x00007ffef99f6000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f50834dc000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f50834ba000)
    libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007f5083498000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f50832cd000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f508558d000)

I don't think the cosmopolitan project is very relevant here. Singularity can only run under Linux, as it uses specific features of the Linux kernel that other operating systems do not have.

[diyism]

Singularity uses relatively low-level code, including CGO code that will link against a system libc and libseccomp. It is not a pure static binary. Generally if you build it on system X it will work on system Y if system Y has a newer glibc. CentOS 7 is, for example, using an older glibc than Debian 10 so a build on Debian 10 will not work on CentOS 7.

$ ldd $(which singularity)
  linux-vdso.so.1 (0x00007ffef99f6000)
  libdl.so.2 => /lib64/libdl.so.2 (0x00007f50834dc000)
  libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f50834ba000)
  libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007f5083498000)
  libc.so.6 => /lib64/libc.so.6 (0x00007f50832cd000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f508558d000)

I don't think the cosmopolitan project is very relevant here. Singularity can only run under Linux, as it uses specific features of the Linux kernel that other operating systems do not have.

Yes, I think cosmopolitan libc maybe can help resolve the problem about different libc.so.6 on CentOS7 and Debian 10, but it won't resolve different go runtime and cgo binding, that part needs google to build a cross-platform single package golang runtime.

[dtrudg]

Yes, I think cosmopolitan libc maybe can help resolve the problem about different libc.so.6 on CentOS7 and Debian 10, but it won't resolve different go runtime and cgo binding, that part needs google to build a cross-platform single package golang runtime.

This is unlikely to be something that is practical. For now, I'd recommend you build Singularity on a system with the same or older version of glibc as the system on which you will deploy it. You may wish to use the in-container build mentioned above by @GH-maggio - though you might need to drop to CentOS 7.