So the basic purpose of a library is to allow code that does some useful thing to be easily used in multiple programs. Like say math functions beyond what is in the language it self or creating network connections.

When you build a program with multiple source files there are many steps. First each file compiled into an object file. This is machine code but wherever you have calls into other files it just inserted a note that basicly says connect this call to this part of another file. So for example connect this call to SquareRoot function in Math library.

After that has been done to every file needed then the linker steps in. It grabs all the object files combines them into one big file and then looks for all the notes that say connect this call to that function and replaces them with actual calls to the address where it put that function.

That is static linking. All the code ends up in a big executable. Simple but it has two big problems. The first is size. Doing it this way means every program that takes the squareroot of something has a copy of the entire math library. This adds up. Second is if there is an error in the math library every program needs to be rebuilt for the fix to apply.

Enter dynamic linking. With that the linker replaces the note to connect to the SquareRoot function in math library with code that requests the connection be made by the operating system.

Then when the program is run the OS gets a list of the libraries needed by the program, finds them, copies them into the memory reserved for that program, and connects them. These are .so files on Linux and .dll on Windows.

Now the os only needs one copy of math.so and if there is a error in the library a update of math.so can fix all the programs that use it.

For GPL vs LGPL this is an important distinction. The main difference between them is how they treat libraries. (There are other differences and this is not legal advice)

So if math.so is GPL and your code uses it as a static link or a dynamic link you have to providd a copy of the source code for your entire program with any executable and licence it to them under the GPL.

With LGPL it's different. If math.so is staticly linked it acts similar to the GPL. If it's dynamicly linked you only have to provide the source to build math.so and licences it under LGPL. So you don't have to give away all your source code but you do have to provide any changes to the math library you made. So if you added a cubeRoot function to the math library you would need to provide that.

There are two ways of using library code in an executable program: dynamically linked libraries – also shared libraries – (these are DLL files on Windows, so files on Linux, dylib files on Mac), and statically linking libraries, which are embedded into the program executable at build time (specifically the link step which is generally the last).

Dynamically linked libraries just store a reference to the library file name, and when the program is run, the dynamic linker searches for these library files on disk and loads them into the program memory, whereas as I already said above statically linked libraries already are part of the program executable code so nothing special has to be done there at runtime.

This has nothing to do with bin packages inherently, which usually use at least a couple dynamically linked libraries anyway (libc at least). In fact every Rust program dynamically links to libc by default as at least glibc is impossible afaik to statically link. Some of them ship dynamic libraries along with the program binary (you see this a lot with Qt since it is pretty hard to link statically), some of them link their dependencies statically, some just expect the system to have certain versions of shared libraries available.

The special thing about Rust is that it really does not want you to output dynamically linked Rust libraries and link them to Rust programs, at least if they're not inside the same project, since it does not have a stable interface for Rust code to Rust code calls (and a couple other reasons). This means you cannot ship a Rust shared library as a system package that programs in other packages can link against, like you can with for example C or Swift languages. Every dependency has to be built inside the same project the final executable is also in.

library code licensed under it must be able to be replaced.

Does this mean you need to be able to make a reproducible build? Or need to be able to swap code for something else? Wouldn’t that inherently break a program?

It does not mean you need to make a reproducable build, it just means users must be able to modify the LGPL licensed parts. For example, the library loads a file from a specific path that you want to change, you must be able to change that path by editing the library source code. This is trivial if it's a shared library since you can just build your own where the path is changed and tell the dynamic linker to load that instead of the original, but with a closed-source statically linked binary you cannot easily change it if it does not provide the object files. These are essentially mostly final compiled code produced from source code files but not yet linked together into an executable, and significantly the LGPL parts are isolated files which can be swapped out with your own and then linked together again.

Doing this does not inherently break a program as long as the interface of the library (like function names, parameter types, general behavior of the code) stays compatible with the original one shipped with the program.