[Slackbuilds-users] Build Environment Reminder

[Yiannis]

Ah there is an email I sent before 2-3 hours that everything was explained
also new slackbuild.tar.gz was attached that by mistake was sent directly
to

*Christoph Willing but ont in the list!*
*Please *
*Christoph Willing can you cc it to list?*

*thank you!*


Στις Πέμ 13 Αυγ 2026 στις 8:36 μ.μ., ο/η Yiannis <rizitis at gmail.com> έγραψε:

> 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 :)
>
> Στις Πέμ 13 Αυγ 2026 στις 7:26 μ.μ., ο/η Lumin Etherlight via
> SlackBuilds-users <slackbuilds-users at slackbuilds.org> έγραψε:
>
>> Yiannis <rizitis at gmail.com> writes:
>>
>> > 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
>>
>>         I don't see how this differs in a meaningful
>>   way from the existing solution that was refused by
>>   the SBo admins.  The only minor difference is that
>>   you're extracting Signal from  a snap instead of a
>>   .deb archive.  The testing glibc is installed into
>>   /opt, and Signal binaries  are patched to point to
>>   that glibc instead of  the system one.  If there's
>>   some  other important  difference here,  please do
>>   explain it a bit more.
>>
>> Best Regards,
>> Lumin Etherlight
>> _______________________________________________
>> 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/20260813/55a503b4/attachment-0001.htm>