Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 10:55 UTC (Tue) by joib (subscriber, #8541)
In reply to: Shared libraries by xnox
Parent article: APT Rust requirement raises questions

If it's just across multiple related binaries, wouldn't a better approach be to use a multi-call binary like AFAIU uutils is using (or busybox for an example in C land)?

to post comments

Shared libraries

Posted Nov 25, 2025 18:00 UTC (Tue) by ssokolow (guest, #94568) [Link]

I believe it's intended for embedded use, where they can update the entire image in one go to keep everything consistent but they may want to add and remove modules depending on the context.

(eg. I could see that being used for something similar to how, as explained by the me_cleaner docs, Intel's UEFI is made of modular blocks and the firmware is updated as one blob, but each motherboard model will have different blocks present and absent... before Intel revised their signing to disallow it, me_cleaner would delete some of the modules.)

Shared libraries

Posted Nov 25, 2025 19:34 UTC (Tue) by bluca (subscriber, #118303) [Link] (3 responses)

Multicall binaries are a horrible hack. Anything there's any security policy in place, running one command means you can run any of them.

Shared libraries

Posted Nov 26, 2025 2:34 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

If your security depends on limiting which binaries you can run by name, then it's dead anyway.

Shared libraries

Posted Nov 26, 2025 11:21 UTC (Wed) by bluca (subscriber, #118303) [Link] (1 responses)

Except of course "depends on" is something you have hallucinated all by yourself

Shared libraries

Posted Nov 26, 2025 18:38 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

I mean, you yourself said that. Also, you can still limit the available command set with multicall binaries, although it requires some support from the binary.

Shared libraries

Posted Nov 25, 2025 19:36 UTC (Tue) by willy (subscriber, #9762) [Link] (2 responses)

Ok, but going back to the libtiff example, we probably don't want a multi call binary that includes every app that wants to process TIFFs.

I really wish something like Microsoft's OLE were more acceptable where we'd essentially have a bunch of methods we could invoke on a tiff object that was handled by a different process.

Shared libraries

Posted Nov 26, 2025 1:57 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

ISTR the Mill Computing (vaporware) ISA allows for efficient cross-context function calls.

https://millcomputing.com/topic/inter-process-communication/

Shared libraries

Posted Nov 26, 2025 4:06 UTC (Wed) by willy (subscriber, #9762) [Link]

Yeah, iAPX 432 also optimised for this use case ;-)