several pkgforge AppImages segfault on TCL 17.1 x86_64

[GNUser]

The folks at pkgforge are a bit surprised that several of their demo AppImages segfault on TCL. Discussion is here:
https://github.com/pkgforge-dev/Anylinux-AppImages/issues/766

Does TCL provide a live iso that they could use for troubleshooting?

[GNUser]

Problem had something to do with linker cache working a little differently in TCL than in other distros. We sorted it out.

Solved.

[Rich]

Hi Paul_123
While I was able to follow the general gist of the issue, I must
admit some of it went over my head.

Maybe you could take a look and tell us what you think?
The explanation of the cause begins here:
https://github.com/pkgforge-dev/Anylinux-AppImages/issues/766#issuecomment-5182763837

[Paul_123]

I read it yesterday, the way I read it is that the ld.so.cache generated on tinycore only has old cache format, and is lacking newer features in the cache.

Now the question is why is the newer stuff being left out of the cache is something that I'm not familiar with.   Is it something that gets stripped out of the .so files?

[Juanito]

I seem to remember that ldconfig in the base is from uclibc?

[Paul_123]

Is there an extension or can you just put the full glibc ldconfig somewhere for gnuser to test?

[Rich]

Hi Paul_123
glibc_apps has ldconfig:
http://tinycorelinux.net/17.x/x86_64/tcz/glibc_apps.tcz.info
http://tinycorelinux.net/17.x/x86_64/tcz/glibc_apps.tcz.list

I check on my TC14 x86_64 install and the the base ldconfig is 80344 bytes
and the glibc_apps version of ldconfig is 835304 bytes. So that's probably
a full version of ldconfig.

[Juanito]

..and the glibc_apps version of ldconfig is 835304 bytes. So that's probably
a full version of ldconfig.

Yes, it is 

[GNUser]

The pkgforge guys rebuilt all their demo AppImages so that they would also work on TCL, so I can't point you to any upstream AppImages that are affected by this issue.

If you want to reproduce the issue, I still have the dino AppImages that I built, here: https://github.com/bdantas/dino-appimage/releases/tag/0.5.1-3%402026-08-04_1785858047 (don't download the AppImages built after that one, since those have the fix and will not reproduce the linker cache problem).

Assuming you are on x86_64, just download Dino-0.5.1-3-anylinux-x86_64.AppImage, make it executable, then run it like so:

Code: [Select]

$ APPIMAGE_DEBUG=1 Dino-0.5.1-3-anylinux-x86_64.AppImage
That should reproduce the problem if anyone wishes to reproduce it, with a debug file to go along with it.

Note: I don't think this is an active problem anymore after the tweak* they made to the  ld-linux-x86-64.so.2  living inside the AppImages.

* The tweak was this command:

Code: [Select]

sed -i -e 's|/etc/ld.so.cache|/xxx/ld.so.cache|g' ./AppDir/lib/ld-linux-x86-64.so.2


[Rich]

Hi GNUser
I downloaded and ran the AppImage on my TC14 x86_64 system.

Using the result of the base ldconfig:

Code: [Select]

tc@HP-G62:~/AppImage$ sudo /sbin/ldconfig
tc@HP-G62:~/AppImage$ ldconfig -p | head -n1
1392 libs found in cache `/etc/ld.so.cache'
tc@HP-G62:~/AppImage$ hexdump -C -n 64 /etc/ld.so.cache
00000000  6c 64 2e 73 6f 2d 31 2e  37 2e 30 00 70 05 00 00  |ld.so-1.7.0.p...|
00000010  03 00 00 00 00 00 00 00  0f 00 00 00 03 00 00 00  |................|
00000020  2d 00 00 00 3b 00 00 00  03 00 00 00 58 00 00 00  |-...;.......X...|
00000030  69 00 00 00 03 00 00 00  89 00 00 00 9a 00 00 00  |i...............|
00000040
tc@HP-G62:~/AppImage$
tc@HP-G62:~/AppImage$
tc@HP-G62:~/AppImage$ ls -l /etc/ld.so.cache
-rw-r--r-- 1 root root 85716 Aug  6 10:23 /etc/ld.so.cache
tc@HP-G62:~/AppImage$ APPIMAGE_DEBUG=1 ./Dino-0.5.1-3-anylinux-x86_64.AppImage
Dino-0.5.1-3-anylinux-x86_64.AppImage: failed to utilize FUSE during startup!
100%
Debug log at: '/home/tc/AppImage/Dino-0.5.1-3-anylinux-x86_64.AppImage-debug.log'This resulted in a debug file ending with  "Segmentation fault".

Using the result of the glibc_apps,tcz ldconfig:

Code: [Select]

tc@HP-G62:~/AppImage$ sudo /usr/sbin/ldconfig
tc@HP-G62:~/AppImage$ ldconfig -p | head -n1
919 libs found in cache `/etc/ld.so.cache'
tc@HP-G62:~/AppImage$ hexdump -C -n 64 /etc/ld.so.cache
00000000  67 6c 69 62 63 2d 6c 64  2e 73 6f 2e 63 61 63 68  |glibc-ld.so.cach|
00000010  65 31 2e 31 97 03 00 00  71 6c 00 00 02 00 00 00  |e1.1....ql......|
00000020  cc c2 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  03 03 00 00 56 a9 00 00  47 a9 00 00 00 00 00 00  |....V...G.......|
00000040
tc@HP-G62:~/AppImage$
tc@HP-G62:~/AppImage$
tc@HP-G62:~/AppImage$ ls -l /etc/ld.so.cache
-rw-r--r-- 1 root root 49939 Aug  6 10:26 /etc/ld.so.cache
tc@HP-G62:~/AppImage$ APPIMAGE_DEBUG=1 ./Dino-0.5.1-3-anylinux-x86_64.AppImage
Dino-0.5.1-3-anylinux-x86_64.AppImage: failed to utilize FUSE during startup!
100%
Debug log at: '/home/tc/AppImage/Dino-0.5.1-3-anylinux-x86_64.AppImage-debug.log'This resulted in a window opening up with a small gray image in the
center and a blue rectangular button with no label below the image.
There was also a small popup asking about an update (Yes/No).
I clicked No and it went away.
There was no  "Segmentation fault"  in the debug file.

[GNUser]

Hi Rich. Thanks for the information. So the segfault is specific to uclibc's ldconfig.

I wonder if the segfault is due to a bug in uclibc's ldconfig or simply a result of pkgforge making assumptions that don't apply to uclibc's ldconfig. I'll ask the pkgforge folks. They're pretty sharp.

[GNUser]

Our default (uclibc) ldconfig is innocent. It is a glibc bug: The glibc linker (which is packaged in the appimages) gags on uclibc's cache format.

See here: https://github.com/pkgforge-dev/Anylinux-AppImages/issues/766#issuecomment-5208027814

Because TCL keeps it simple, I think pretty much every problem I've ever had while using it turned out to be a bug in some other project

Rich, please go ahead and mark the thread as Solved

[Rich]

Hi GNUser
If you install glibc_apps and run:

Code: [Select]

sudo /usr/sbin/ldconfigyou could forward that  /etc/ld.so.cache  and see what they say
about that one.

I took a look at:

Code: [Select]

ldconfig -p | lessfor both versions of ldconfig. The reason the glibc version output is smaller
is they output  libName.so and libName.so.n but not libName.so.n.n where
n is a number.