Tiny Core Linux
Off-Topic => Off-Topic - Tiny Core Lounge => Topic started by: GNUser on August 04, 2026, 12:32:02 PM
-
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?
-
Problem had something to do with linker cache working a little differently in TCL than in other distros. We sorted it out.
Solved.
-
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
-
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?
-
I seem to remember that ldconfig in the base is from uclibc?
-
Is there an extension or can you just put the full glibc ldconfig somewhere for gnuser to test?
-
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.
-
..and the glibc_apps version of ldconfig is 835304 bytes. So that's probably
a full version of ldconfig.
Yes, it is :)
-
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:
$ 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:
sed -i -e 's|/etc/ld.so.cache|/xxx/ld.so.cache|g' ./AppDir/lib/ld-linux-x86-64.so.2
-
Hi GNUser
I downloaded and ran the AppImage on my TC14 x86_64 system.
Using the result of the base ldconfig:
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:
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.
-
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.
-
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 ;D
Rich, please go ahead and mark the thread as Solved :)
-
Hi GNUser
If you install glibc_apps and run:
sudo /usr/sbin/ldconfigyou could forward that /etc/ld.so.cache and see what they say
about that one.
I took a look at:
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.
-
you could forward that /etc/ld.so.cache and see what they say
about that one.
Hi Rich. I think the pkgforge developers are happy with their solution and have moved on.
Thanks to this issue, the pkgforge developers discovered that not all linker cache formats are compatible with glibc's linker (which comes bundled with their AppImages). So they made the clever decision to hack their glibc linker so that it doesn't parse /etc/ld.so.cache at all. I think their decision makes sense--they want their AppImages to be "anylinux-compatible" (i.e., distro-agnostic and libc-agnostic).
-
Hi GNUser
Fair enough. But maybe you could satisfy my curiosity.
The individual that did the failure analysis stated:
TCL's cache is also perfectly reverse-sorted — 1014 of 1014 adjacent pairs are in descending _dl_cache_libcmp order. No working ldconfig produces this; ldconfig always writes ascending.
I see the same behavior whether I run:
/sbin/ldconfig -p | lessor:
/usr/sbin/ldconfig -p | less
If you have a chance, check your Devuan install and let me
know if the results are sorted in ascending or descending order.
-
devuan bash here
uname -a
Linux xxxxx 6.1.0-52-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.180-1 (2026-08-03) x86_64 GNU/Linux
running:
/sbin/ldconfig -p | less
results:
1063 libs found in cache `/etc/ld.so.cache'
libz3.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libz3.so.4
libzvbi.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libzvbi.so.0
libzvbi-chains.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libzvbi-chains.so.0
...
libCbc.so.3 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libCbc.so.3
libBrokenLocale.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libBrokenLocale.so.1
ld-linux-x86-64.so.2 (libc6,x86-64) => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
Cache generated by: ldconfig (Debian GLIBC 2.36-9+deb12u14) stable release version 2.36
for completeness:
bash: /usr/sbin/ldconfig: No such file or directory
keep up the great work folks!
-
Hi gadget42
That looks like descending order to me.
-
Hi Rich. The /etc/ld.so.cache from my Devuan system is attached.
-
Hi GNUser
Thanks, that appears to be sorted in descending order too.
-
The individual that did the failure analysis stated:
...No working ldconfig produces this; ldconfig always writes ascending.
Hi Rich. It was not an individual that did the failure analysis. The pkgforge guys fed my TCL's /etc/ld.so.cache to AI then they copy-pasted the AI's verbal diarrhea.
Since Devuan has a working ldconfig which writes the cache in descending order, AI's claim in the above quote is incorrect.
-
Hi GNUser
... It was not an individual that did the failure analysis. ...
I see. I guess that explains this statement:
Here is an analysis made by GLM5.2 of this file. So be aware this may not be 100% correct:
The first time I read it I thought "GLM5.2, what an odd user name", but
then thought "who am I to judge" and dismissed it. :)