libnsl.so.1 missing from AppImage v0.19-23756

[brianredbeard]

After updating using zsync from v0.19-23578 to v0.19-23756, the FreeCAD appimage fails with the following error:

$ ./FreeCAD_0.19-23756-Linux-Conda_glibc2.12-x86_64.AppImage 
/tmp/.mount_FreeCAuZGeOF/usr/bin/freecad: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

Indeed, it does seem that the library is missing from the bundle. After using $ ./FreeCAD_0.19-23756-Linux-Conda_glibc2.12-x86_64.AppImage --appimage-mount and changing into the directory specified on STDOUT (/tmp/.mount_FreeCAnPMqLM/) I see the following:

$ cd /tmp/.mount_FreeCAnPMqLM/
$ ls -la
-rwxrwxr-x.  1 root root  1411 Oct 26 01:18 AppRun
lrwxrwxrwx.  1 root root    17 Oct 21 23:41 .DirIcon -> freecad_conda.png
-rwxrwxr-x.  1 root root   250 Oct 21 23:41 freecad_conda.desktop
-rwxrwxr-x.  1 root root  3744 Oct 21 23:41 freecad_conda.png
-rw-rw-r--.  1 root root 14493 Jan 24 06:32 packages.txt
drwxrwxr-x. 24 root root     0 Jan 24 06:32 usr
$ grep -i nsl packages.txt
$ find usr/ -name "libnsl.*"
$ ls -l usr/lib/libns*
-rwxrwxr-x. 1 root root  305080 Jan  3 13:00 usr/lib/libnspr4.so
-rwxrwxr-x. 1 root root 1430424 Jan 22 13:17 usr/lib/libnss3.so
-rwxrwxr-x. 1 root root  585048 Jan 22 13:17 usr/lib/libnssckbi.so
-rwxrwxr-x. 1 root root  192848 Jan 22 13:17 usr/lib/libnssckbi-testlib.so
-rw-rw-r--. 1 root root     899 Jan 22 13:17 usr/lib/libnssdbm3.chk
-rwxrwxr-x. 1 root root  161160 Jan 22 13:17 usr/lib/libnssdbm3.so
-rwxrwxr-x. 1 root root   17856 Jan 22 13:17 usr/lib/libnsssysinit.so
-rwxrwxr-x. 1 root root  241152 Jan 22 13:17 usr/lib/libnssutil3.so

Related to this, I see that there are multiple identical copies of libnsl in older AppImages (in this example v0.19-23578):

$ find usr/lib/ -maxdepth 1  -name "libnsl*"  -ls  -exec sha256sum {} \; 
3464105691     91 -rw-r--r--   1 root     root        93128 Jan  3 01:45 usr/lib/libnsl-2.23.so
a78023950570485a2d80bac92ecbde292f7a1f4a63bf81bc540dca478c963921  usr/lib/libnsl-2.23.so
3464105723     91 -rw-r--r--   1 root     root        93128 Jan  3 01:45 usr/lib/libnsl.so.1
a78023950570485a2d80bac92ecbde292f7a1f4a63bf81bc540dca478c963921  usr/lib/libnsl.so.1

We see that we have the same SHA256 hash with different paths and different inodes. This is different than the behavior of other libraries (e.g. libkrad, which uses a normative set of cascading symbolic links):

$ find usr/lib/ -maxdepth 1  -name "libkrad*"  -ls  -exec sha256sum {} \; 
3254656497      0 lrwxrwxrwx   1 root     root           14 Jan  3 01:44 usr/lib/libkrad.so -> libkrad.so.0.0
c3138cc655fd1dd6987118cd0e2d899bf0b986b252ac5a8c33011ec0057b337c  usr/lib/libkrad.so
3254656535      0 lrwxrwxrwx   1 root     root           14 Jan  3 01:44 usr/lib/libkrad.so.0 -> libkrad.so.0.0
c3138cc655fd1dd6987118cd0e2d899bf0b986b252ac5a8c33011ec0057b337c  usr/lib/libkrad.so.0
3254656573     44 -rw-rw-r--   1 root     root        44880 Nov 17 16:14 usr/lib/libkrad.so.0.0
c3138cc655fd1dd6987118cd0e2d899bf0b986b252ac5a8c33011ec0057b337c  usr/lib/libkrad.so.0.0

My assumption for this being that the cp command originally introduced in 49f8a39 and carried forward into the various build scripts is dereferencing the symbolic link created by the underlying packaging system used to put libnsl in place.

[looooo]

possible the copying is not working anymore after moving to github-actions. Best to look into the log files.

[luzpaz]

@brianredbeard Is this also true for the latest FC appimage revision? https://github.com/FreeCAD/FreeCAD/releases/download/0.19_pre/FreeCAD_0.19-24212-macOS-x86_64-conda.dmg

[looooo]

@luzpaz you linked the osx-bundle. I guess we are talking about the appimage here.

[luzpaz]

sorry, i meant the appimage link

[luzpaz]

I guess this is obsolete now. Closing