<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><font face="monospace">I see fr</font><font
face="monospace">om Yiannis' earlier email to me directly that
he fully credits Lumin for the main idea.<br>
<br>
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.<br>
<br>
chris<br>
<br>
<br>
<br>
</font>On 14/8/26 01:31, Yiannis wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADV5w3wmEXXFBV1MMJ=7m4CEHVfnqTZh3GEPNF9dnppMHN01mQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<pre>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.
</pre>
<pre>PS. in tar.gz included a python3 script I use to find snap package`s url for download. (python3 snap-info.py <pkg_name>)</pre>
<pre>
[1]: <a
href="https://lumin.etherlight.link/s/2C2606/saNeW/slackware-signal-glibc-workaround.sh"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lumin.etherlight.link/s/2C2606/saNeW/slackware-signal-glibc-workaround.sh</a>
</pre>
<br>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">Στις Πέμ 13 Αυγ 2026 στις
4:30 μ.μ., ο/η Christoph Willing <<a
href="mailto:chris.willing@linux.com" moz-do-not-send="true"
class="moz-txt-link-freetext">chris.willing@linux.com</a>>
έγραψε:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div><font face="monospace">I've never use signal before so
can't check history but QR link & sync seem to work
OK here.<br>
<br>
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.<br>
<br>
chris<br>
<br>
<br>
</font>On 13/8/26 21:06, Yiannis wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Just to be clear, this is not the same as
installing the testing glibc.<br>
<br>
Nothing on the system changes. System glibc stays
2.33. No upgradepkg of a core package, no
ld.so.conf, no ldconfig.<br>
<br>
What the script does:<br>
<br>
- unpacks the snap into /opt/Signal/signal-desktop<br>
- unpacks aaa_glibc-solibs-2.42 into the same
prefix, as a build source like any tarball<br>
- patchelf on the Electron binary so its PT_INTERP
and DT_RPATH point there<br>
<br>
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.<br>
<br>
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.<br>
<br>
Attached if anyone wants to look.<br>
<br>
</div>
IF admins and the maintainer agree with that then a
desktop entry and an icon needed, now run only from
the terminal.<br>
<br>
</div>
Thank you.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Στις Πέμ 13 Αυγ 2026
στις 12:05 μ.μ., ο/η Yiannis <<a
href="mailto:rizitis@gmail.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">rizitis@gmail.com</a>>
έγραψε:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<div>Please give me some time, I have an idea and
it looks that works! <br>
</div>
When I finish and be sure I will upload it here
and IF maintainer and SBo admins agree you can
adopt it.<br>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Στις Πέμ 13 Αυγ
2026 στις 7:13 π.μ., ο/η Willy Sudiarto Raharjo
<<a href="mailto:willysr@slackbuilds.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">willysr@slackbuilds.org</a>>
έγραψε:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>
Signal blocks old versions of their software<br>
> from connecting to the network. I had to
figure<br>
> out the binary patching thing because
the last<br>
> 15.0 glibc-compatible version I had was
finally<br>
> blocked from connecting to the Signal
network.<br>
><br>
> If patching the rpath to use an
isolated new<br>
> glibc-opt without migrating the whole OS is
not an<br>
> acceptable solution for the SlackBuilds.org
repo,<br>
> then removing the Signal SlackBuild is the
option<br>
> that makes sense, in my opinion. People who
still<br>
> want to use Signal will have to install it
from a<br>
> different 3rd party. If that happens, I
might end<br>
> up packaging the patched version myself,
and then<br>
> redistribute it on my site for others to
use.<br>
<br>
<br>
What about the AppImage format?<br>
will that work?<br>
i assume it's all contained in a single package,
so no link to<br>
system-based GLIBC<br>
<br>
<br>
--<br>
Willy Sudiarto Raharjo<br>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">SlackBuilds-users@slackbuilds.org</a><br>
<a
href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a
href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://slackbuilds.org/faq/</a><br>
<br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
SlackBuilds-users mailing list
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">SlackBuilds-users@slackbuilds.org</a>
<a
href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a>
Archives - <a
href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a>
FAQ - <a href="https://slackbuilds.org/faq/" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://slackbuilds.org/faq/</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>