News for hackers. Stuff that matters.
Re:How Swift achieved dynamic linking where Rust couldn't (2... by pjmlp on Sunday February 21, 2021 @02:39AM (#26211641)
First of all, depending on the OS there are no syscalls to call to, Linux is the exception here.

Everyone else has to go through dlopen, LoadLibrary, or whatever alternative the OS offers.

Which is exactly the same code path that at some level the OS dynamic linker relies on.

If you are statically linking everything, then there are no libraries to give input to dlopen anyway, it doesn't load .a files, and .so is not what we want to support anyway.

But lets keep the assumption that in the world of static linking advocacy, explicitly loading dynamic libraries is acceptable.

SO now, not only has the application to do the job of mapping dynamic library symbols to function pointers, they are constrained to C ABI function calls, which is not Rust anyway.

As for you Linux based assumption, there are OSes, where dynamic linking doesn't take place before the PC jumps to main, you can do deferred dynamic linking. The call sites are marked for triggering a page fault on call, which only when it happens, will the OS look around for code to load.

This is how managed languages like Java and C# work, which many keep forgetting there are also AOT compilers, just in case the VM arguments comes into play.

But since we are talking about systems languages, you can find this feature on Windows and Aix, just to give two examples how the OS world isn't everywhere a Linux clone.

https://docs.microsoft.com/en-us/cpp/build/reference/linker-...

https://www.ibm.com/support/knowledgecenter/ssw_aix_71/gener...

There are no comments on this comment yet.