Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 0:34 UTC (Tue) by pabs (subscriber, #43278)
In reply to: Shared libraries by ballombe
Parent article: APT Rust requirement raises questions

Rust already supports shared libraries (dylib), IIRC the ABI is not yet stable though.

https://doc.rust-lang.org/reference/linkage.html

The problem though is the culture of the Rust ecosystem; much of it prefers static linking, dislikes distros and probably would reject patches to introduce dylibs for each package.

to post comments

Shared libraries

Posted Nov 25, 2025 4:14 UTC (Tue) by xnox (subscriber, #63320) [Link] (9 responses)

It is somewhat limited in its use.

It doesn't provide stable abi - one can use them to share code across multiple related binaries, think private .so

It also is unsafe and removes type checking - which defeats the point of rust to begin with.

Shared libraries

Posted Nov 25, 2025 10:55 UTC (Tue) by joib (subscriber, #8541) [Link] (8 responses)

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)?

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 ;-)