[Slackbuilds-users] Build Environment Reminder

Thu Aug 13 21:57:08 UTC 2026

I see from Yiannis' earlier email to me directly that he fully credits 
Lumin for the main idea.

One more possibility would be to use the built source code rather than 
an appImage. In this case it is almost the same as Lumin's original 
proposal but with the advantage of keeping the updated glibc relatively 
private.

chris

On 14/8/26 01:31, Yiannis wrote:
> Thanks! but the main idea was Lumin`s script :)
>
> So looking better Lumin`s [1] script caught something I had missed -- I was only patching the signal-desktop binary.
> Lumin patch every executable in the directory, and that turned out to matter:
> chrome_crashpad_handler is exec'd separately, so it kept its own PT_INTERP and would have started against the system 2.33
> while inspecting a 2.42 process. Only shows up when something else has already gone wrong, so I would never have caught it in testing.
>
> Also took $ORIGIN in the rpath from him -- more robust than the absolute path I had.
>
> for b in signal-desktop chrome_crashpad_handler; do
>    printf '== %s\n' "$b"
>    readelf -d /opt/Signal/signal-desktop/opt/Signal/$b | grep -E 'RPATH|RUNPATH'
> done
> == signal-desktop
>   0x000000000000000f (RPATH)              Library rpath: [$ORIGIN:/opt/Signal/signal-desktop/lib64/incoming]
> == chrome_crashpad_handler
>   0x000000000000000f (RPATH)              Library rpath: [$ORIGIN:/opt/Signal/signal-desktop/lib64/incoming]
>
> Both binaries now resolve to the bundled loader, RPATH not RUNPATH, single libc across all processes per /proc/PID/maps.
>
> PS. in tar.gz included a python3 script I use to find snap package`s url for download. (python3 snap-info.py <pkg_name>)
> [1]:https://lumin.etherlight.link/s/2C2606/saNeW/slackware-signal-glibc-workaround.sh
>
>
> Στις Πέμ 13 Αυγ 2026 στις 4:30 μ.μ., ο/η Christoph Willing 
> <chris.willing at linux.com> έγραψε:
>
>     I've never use signal before so can't check history but QR link &
>     sync seem to work OK here.
>
>     I'm not sure if it meets all other admins requirements but if put
>     to a vote my vote would be "aye" if only because it's such a cute
>     solution.
>
>     chris
>
>
>     On 13/8/26 21:06, Yiannis wrote:
>>     Just to be clear, this is not the same as installing the testing
>>     glibc.
>>
>>     Nothing on the system changes. System glibc stays 2.33. No
>>     upgradepkg of a core package, no ld.so.conf, no ldconfig.
>>
>>     What the script does:
>>
>>     - unpacks the snap into /opt/Signal/signal-desktop
>>     - unpacks aaa_glibc-solibs-2.42 into the same prefix, as a build
>>     source like any tarball
>>     - patchelf on the Electron binary so its PT_INTERP and DT_RPATH
>>     point there
>>
>>     So those .so files are reachable by exactly one binary. Nothing
>>     else on the machine can see them, and removepkg takes them all
>>     with it.
>>
>>     Checked: /proc/PID/maps across all 7 Signal processes shows only
>>     the bundled libc, never the host 2.33. QR link, full history
>>     sync, send and receive all work. sbopkglint passes.
>>
>>     Attached if anyone wants to look.
>>
>>     IF admins and the maintainer agree with that then a desktop entry
>>     and an icon needed, now run only from the terminal.
>>
>>     Thank you.
>>
>>     Στις Πέμ 13 Αυγ 2026 στις 12:05 μ.μ., ο/η Yiannis
>>     <rizitis at gmail.com> έγραψε:
>>
>>         Please give me some time, I have an idea and it looks that
>>         works!
>>         When I finish and be sure I will upload it here and IF
>>         maintainer and SBo admins agree you can adopt it.
>>
>>
>>         Στις Πέμ 13 Αυγ 2026 στις 7:13 π.μ., ο/η Willy Sudiarto
>>         Raharjo <willysr at slackbuilds.org> έγραψε:
>>
>>             >       Signal blocks old versions of their software
>>             >  from connecting  to the network.  I  had to figure
>>             >  out  the binary  patching thing  because the  last
>>             >  15.0  glibc-compatible version  I had  was finally
>>             >  blocked from connecting to the Signal network.
>>             >
>>             >        If patching the rpath to use an isolated new
>>             >  glibc-opt without migrating the whole OS is not an
>>             >  acceptable solution for  the SlackBuilds.org repo,
>>             >  then removing the Signal  SlackBuild is the option
>>             >  that makes sense, in my opinion.  People who still
>>             >  want to use Signal will  have to install it from a
>>             >  different 3rd party.  If that happens, I might end
>>             >  up packaging the patched  version myself, and then
>>             >  redistribute it on my site for others to use.
>>
>>
>>             What about the AppImage format?
>>             will that work?
>>             i assume it's all contained in a single package, so no
>>             link to
>>             system-based GLIBC
>>
>>
>>             --
>>             Willy Sudiarto Raharjo
>>             _______________________________________________
>>             SlackBuilds-users mailing list
>>             SlackBuilds-users at slackbuilds.org
>>             https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>>             Archives -
>>             https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>>             FAQ - https://slackbuilds.org/faq/
>>
>>
>>     _______________________________________________
>>     SlackBuilds-users mailing list
>>     SlackBuilds-users at slackbuilds.org
>>     https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>>     Archives -https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>>     FAQ -https://slackbuilds.org/faq/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260814/986f6520/attachment.htm>