[Slackbuilds-users] Build Environment Reminder

[Greg Tourte]

Thanks all,

I have pushed a PR on codeberg to update signal-desktop to the lastest
version which include the workaround for -stable vanilla. The script test
for the version of glibc and only apply the workaround if the system is
running too old a version.

https://codeberg.org/ArTourter/slackbuilds/commit/c2e89a3839433860355bf387e51228c85615126b
https://codeberg.org/SlackBuildsOrg/slackbuilds/pulls/34

Let me know if something is not working as expect on your system.

Cheers

Greg

On Fri, 14 Aug 2026 at 02:14, Willy Sudiarto Raharjo <
willysr at slackbuilds.org> wrote:

> >You're right that the technique is the same -- bundled glibc, patched
> >interpreter and rpath.
> >I took $ORIGIN and the patch-everything loop from your script.
> >The difference isn't technical, it's what each one asks the repo for.
> >
> >Yours needs a second thing to exist: either a glibc-opt-bin SlackBuild
> >in the repo, or the user runs your apply script by hand.
> >That's what Willy refused -- not the patching, but adding a shared
> >glibc to SBo that other scripts could then depend on.
> > He called it all or nothing, and he was right about that:
> >once glibc-opt-bin exists in the repo, it's a package the admins have
> >to maintain, and your own message anticipated other packages following
> >the same pattern.
> >
> >Now doesn't create anything shared. The .txz is a build-time source,
> >extracted into the package payload the same way any tarball is.
> >What gets installed is a set of .so files under
> >/opt/Signal/signal-desktop/lib64/, reachable only through one binary's
> >PT_INTERP and DT_RPATH.
> >No second package, no REQUIRES, nothing on the system another script
> >could ever link against.
> > It's vendored libraries in one package, which SBo already accepts
> >elsewhere.
> >
> >Concretely, from a user's point of view:
> >
> >- installpkg and it works; no apply step
> >- removepkg takes all of it, including the glibc; no revert step, no
> >/opt/glibc left behind
> >- survives upgradepkg, because the patching is in the SlackBuild rather
> >than something to re-run afterwards
> >- the source has an md5sum in the .info, instead of required a glibc
> >package
> >- system glibc stays 2.33 and no other package sees 2.42
> >
> >So the question for the admins stops being "can SBo ship a glibc" and
> >becomes "can one package carry private libraries under /opt", which is
> >a much smaller question.
> >
> >Its like you run an independent signal-desktop.AppImage with the
> >required glibc included :)
>
> From my *personal perspective*, this approach is fine since it's
> contained *only* for this spesific package, so we can keep using the
> original GLIBC from Slackware 15.0.
> It's like how alienBOB provide some of his package where all
> modules/dependencies are linked statically into his single package
> without linking to outside libraries.
>
> the disadvantages of this approach is that the output package will be
> slightly bigger in size
>
>
> --
> 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260907/61aefc37/attachment-0001.htm>