6 ms·

The commenters below are confusing two things - Rust binaries can be dynamically linked, but because Rust doesn’t have a stable ABI you can’t do this across com

The commenters below are confusing two things - Rust binaries can be dynamically linked, but because Rust doesn’t have a stable ABI you can’t do this across compiler versions the way you would with C. So in practice, everything is statically linked.

eru 1y ago
Static linking also produces smaller binaries and lets you do link-time-optimisation.
- emidln 1y ago
  Static linking doesn't produce smaller binaries. You are literally adding the symbols from a library into your executable rather than simply mentioning them and letting the dynamic linker figure out how to map those symbols at runtime. The sum size of a dynamic binary plus the dynamic libraries may be larger than one static linked binary, but whether that holds for more static binaries (2, 3, or 100s) depends on the surface area your application uses of those libraries. It's relatively common to see certain large libraries only dynamically linked, with the build going to great lengths to build certain libraries as shared objects with the executables linking them using a location-relative RPATH (using the $ORIGIN feature) to avoid the extra binary size bloat over large sets of binaries.
  - IshKebab 1y ago
    Static linking does produce smaller binaries when you bundle dependencies. You're conflating two things - static vs dynamic linking, and bundled vs shared dependencies. They are often conflated because you can't have shared dependencies with static linking, and bundling dynamically linked libraries is uncommon in FOSS Linux software. It's very common on Windows or with commercial software on Linux though.
    - guappa 1y ago
      You know how the page cache works? Static linking makes it not work. So 3000 processes won't share the same pages for the libc but will have to load it 3000 times.
      - mandarax8 1y ago
        You can still statically link all your own code but dynamically link libc/other system dependencies.
        guappa 1y ago
        Not with rust…
        tialaramex 1y ago
        I wonder what happens in the minds of people who just flatly contradict reality. Are they expecting others to go "OK, I guess you must be correct and the universe is wrong"? Are they just trying to devalue the entire concept of truth? [In case anybody is confused by your utterance, yes of course this works in Rust]
        guappa 1y ago
        Can you run ldd on any binary you currently have on your machine that is written in rust? I eagerly await the results!
        tux3 1y ago
        I mean, sure, but what's your point? Here's nu, a shell in Rust: $ ldd ~/.cargo/bin/nu linux-vdso.so.1 (0x00007f473ba46000) libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f47398f2000) libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f4739200000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f473b9cd000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4739110000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4738f1a000) /lib64/ld-linux-x86-64.so.2 (0x00007f473ba48000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f473b9ab000) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f4738e50000) And here's the Debian variant of ash, a shell in C: $ ldd /bin/sh linux-vdso.so.1 (0x00007f88ae6b0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88ae44b000) /lib64/ld-linux-x86-64.so.2 (0x00007f88ae6b2000)
- guappa 1y ago
  Static linking produces huge binaries, it lets you do LTO but the amount of optimisation you can actually do is limited by your RAM. Static linking also causes the entire archive to need constant rebuilds.
  - TuxSH 1y ago
    You don't need LTO to trim static binaries (though LTO will do it), `-ffunction-sections -fdata-sections` in compiler flags combined with `--gc-section` (or equivalent) in linker flags will do it. This way you can get small binaries with readable assembly.
  - eru 1y ago
    > Static linking also causes the entire archive to need constant rebuilds. Only relinking, which you can make cheap for your non-release builds. Dynamic linking needs relinking everytime you run the program!
connicpu 1y ago
Specifically, the rust dependencies are statically linked. It's extremely easy to dynamically link anything that has a C ABI from rust.
quotemstr 1y ago
C++ binaries should be doing the same. Externally, speak C ABI. Internally, statically link Rust stdlib or C++ stdlib.
- pjmlp 1y ago
  OWL, MFC, Qt, VCL, FireMonkey, AppFramework, PowerPlant... Plenty do not, especially on Apple and Microsoft platforms because they always favoured other approaches to bare bones UNIX support on their dynamic linkers, and C++ compilers.
- pjc50 1y ago
  Exporting a C API from a C++ project to consume in another C++ project is really painful. This is how you get COM. (which actually slightly pre-dates C++, I think?)
  - Someone 1y ago
    > This is how you get COM. (which actually slightly pre-dates C++, I think?) No. C++ is from 1985 (https://en.wikipedia.org/wiki/C%2B%2B https://en.wikipedia.org/wiki/C%2B%2B), COM from 1993 (https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model)
  - quotemstr 1y ago
    COM is actually good though. Or if you want another object system, you can go with GObject, which works fine with Rust, C-+, Python, JavaScript, and tons of other things.
pjmlp 1y ago
A culture isse, as in the C++ world, of Apple and Microsoft ecosystems, shipping binary C++ libraries is a common business, even it is compiler version dependent. This is why Apple made such a big point of having a better ABI approach on Swift, after their experience with C++ and Objective-C. While on Microsoft side, you will notice that all talks from Victor Ciura on Rust conferences have dealing with ABI as one of the key points Microsoft is dealing with in the context of Rust adoption.
zozbot234 1y ago
Rust's stable ABI is the C ABI. So you absolutely can dynamically link a Rust-written binary and/or a Rust-written shared library, but the interface has to be pure C. (This also gives you free FFI to most other programming languages.) You can use lightweight statically-linked wrappers to convert between Rust and C interfaces on either side and preserve some practical safety.
- Someone 1y ago
  > but the interface has to be pure C. (This also gives you free FFI to most other programming languages.) Easy, not free. In many languages, extra work is needed to provide a C interface. Strings may have to be converted to zero terminated byte arrays, memory that can be garbage collected may have to be locked, structs may mean having to be converted to C struct layout, etc.

eru 1y ago

Static linking also produces smaller binaries and lets you do link-time-optimisation.

emidln 1y ago
Static linking doesn't produce smaller binaries. You are literally adding the symbols from a library into your executable rather than simply mentioning them and letting the dynamic linker figure out how to map those symbols at runtime. The sum size of a dynamic binary plus the dynamic libraries may be larger than one static linked binary, but whether that holds for more static binaries (2, 3, or 100s) depends on the surface area your application uses of those libraries. It's relatively common to see certain large libraries only dynamically linked, with the build going to great lengths to build certain libraries as shared objects with the executables linking them using a location-relative RPATH (using the $ORIGIN feature) to avoid the extra binary size bloat over large sets of binaries.
- IshKebab 1y ago
  Static linking does produce smaller binaries when you bundle dependencies. You're conflating two things - static vs dynamic linking, and bundled vs shared dependencies. They are often conflated because you can't have shared dependencies with static linking, and bundling dynamically linked libraries is uncommon in FOSS Linux software. It's very common on Windows or with commercial software on Linux though.
  - guappa 1y ago
    You know how the page cache works? Static linking makes it not work. So 3000 processes won't share the same pages for the libc but will have to load it 3000 times.
    - mandarax8 1y ago
      You can still statically link all your own code but dynamically link libc/other system dependencies.
      - guappa 1y ago
        Not with rust…
        tialaramex 1y ago
        I wonder what happens in the minds of people who just flatly contradict reality. Are they expecting others to go "OK, I guess you must be correct and the universe is wrong"? Are they just trying to devalue the entire concept of truth? [In case anybody is confused by your utterance, yes of course this works in Rust]
        guappa 1y ago
        Can you run ldd on any binary you currently have on your machine that is written in rust? I eagerly await the results!
        tux3 1y ago
        I mean, sure, but what's your point? Here's nu, a shell in Rust: $ ldd ~/.cargo/bin/nu linux-vdso.so.1 (0x00007f473ba46000) libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f47398f2000) libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f4739200000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f473b9cd000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4739110000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4738f1a000) /lib64/ld-linux-x86-64.so.2 (0x00007f473ba48000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f473b9ab000) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f4738e50000) And here's the Debian variant of ash, a shell in C: $ ldd /bin/sh linux-vdso.so.1 (0x00007f88ae6b0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88ae44b000) /lib64/ld-linux-x86-64.so.2 (0x00007f88ae6b2000)
guappa 1y ago
Static linking produces huge binaries, it lets you do LTO but the amount of optimisation you can actually do is limited by your RAM. Static linking also causes the entire archive to need constant rebuilds.
- TuxSH 1y ago
  You don't need LTO to trim static binaries (though LTO will do it), `-ffunction-sections -fdata-sections` in compiler flags combined with `--gc-section` (or equivalent) in linker flags will do it. This way you can get small binaries with readable assembly.
- eru 1y ago
  > Static linking also causes the entire archive to need constant rebuilds. Only relinking, which you can make cheap for your non-release builds. Dynamic linking needs relinking everytime you run the program!

connicpu 1y ago

Specifically, the rust dependencies are statically linked. It's extremely easy to dynamically link anything that has a C ABI from rust.

quotemstr 1y ago

C++ binaries should be doing the same. Externally, speak C ABI. Internally, statically link Rust stdlib or C++ stdlib.

pjmlp 1y ago
OWL, MFC, Qt, VCL, FireMonkey, AppFramework, PowerPlant... Plenty do not, especially on Apple and Microsoft platforms because they always favoured other approaches to bare bones UNIX support on their dynamic linkers, and C++ compilers.
pjc50 1y ago
Exporting a C API from a C++ project to consume in another C++ project is really painful. This is how you get COM. (which actually slightly pre-dates C++, I think?)
- Someone 1y ago
  > This is how you get COM. (which actually slightly pre-dates C++, I think?) No. C++ is from 1985 (https://en.wikipedia.org/wiki/C%2B%2B https://en.wikipedia.org/wiki/C%2B%2B), COM from 1993 (https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model)
- quotemstr 1y ago
  COM is actually good though. Or if you want another object system, you can go with GObject, which works fine with Rust, C-+, Python, JavaScript, and tons of other things.

pjmlp 1y ago

A culture isse, as in the C++ world, of Apple and Microsoft ecosystems, shipping binary C++ libraries is a common business, even it is compiler version dependent. This is why Apple made such a big point of having a better ABI approach on Swift, after their experience with C++ and Objective-C. While on Microsoft side, you will notice that all talks from Victor Ciura on Rust conferences have dealing with ABI as one of the key points Microsoft is dealing with in the context of Rust adoption.

zozbot234 1y ago

Rust's stable ABI is the C ABI. So you absolutely can dynamically link a Rust-written binary and/or a Rust-written shared library, but the interface has to be pure C. (This also gives you free FFI to most other programming languages.) You can use lightweight statically-linked wrappers to convert between Rust and C interfaces on either side and preserve some practical safety.

Someone 1y ago
> but the interface has to be pure C. (This also gives you free FFI to most other programming languages.) Easy, not free. In many languages, extra work is needed to provide a C interface. Strings may have to be converted to zero terminated byte arrays, memory that can be garbage collected may have to be locked, structs may mean having to be converted to C struct layout, etc.