4 ms·

Almost every command line tool has runtime dependencies that must be installed on your system. $ ldd /usr/bin/rg linux-vdso.so.1 (0x00007fff45dd7000)

Almost every command line tool has runtime dependencies that must be installed on your system. $ ldd /usr/bin/rg linux-vdso.so.1 (0x00007fff45dd7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000070764e7b1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000070764e6ca000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000070764de00000) /lib64/ld-linux-x86-64.so.2 (0x000070764e7e6000) The worst is compiling a C program with a compiler that uses a more recent libc than is installed on the installation host.

dboon 1y ago
That’s the first rule anyone writing portable binaries learns. Compile against an old libc, and stuff tends to just work.
- delta_p_delta_x 1y ago
  > Compile against an old libc This clause is abstracting away a ton of work. If you want to compile the latest LLVM and get 'portable C++26', you need to bootstrap everything, including CMake from that old-hat libc on some ancient distro like CentOS 6 or Ubuntu 12.04. I've said it before, I'll say it again: the Linux kernel may maintain ABI compatibility, but the fact that GNU libc breaks it anyway makes it a moot point. It is a pain to target older Linux with a newer distro, which is by far the most common development use case.
  - dboon 1y ago
    Definitely, and I know this sounds like ignoring the problem, but in my experience the best solution is to just not use the bleeding edge. Write your code such that you can load it onto (for example) the oldest supported Ubuntu and compile cleanly and you’ll have virtually zero problems. Again, I know that if your goal is to truly ship something written in e.g. C++26 portably then it’s a huge pain. But as someone who writes plain C and very much enjoys it, I think it’s better to skip this class of problem.
    - delta_p_delta_x 1y ago
      > I think it’s better to skip this class of problem. I'll keep my templates, smart pointers, concepts, RAII, and now reflection, thanks. C and its macros are good for compile times but nothing much else. Programming in C feels like banging rocks together.
      - dboon 1y ago
        Agree to disagree, then! Templates, smart pointers, and RAII have cost me far, far more than they’ve paid me back. You should write whatever feels good to you.
        delta_p_delta_x 1y ago
        Happy to. If I may, I have an analogy: C feels a little like survival mode in Minecraft; you have a set of very simple abstractions, a relatively simple language, with which one can build the world (and in many cases, we have). C++ feels like a complex city builder, with lots of tools, designs, and paradigms available, but also allows one to screw up in bigger ways.
bschwindHN 1y ago
Yes but I've never had a native tool fail on a missing libc. I've had several Python tools and JS tools fail on missing the right version of their interpreter. Even on the right interpreter version Python tools frequently shit the bed because they're so fragile.
- mjevans 1y ago
  I have. During system upgrades, usually along unsupported paths. If you're ever living dangerously, bring along busybox-static. It might not be the best, but you'll thank yourself later.
sestep 1y ago
I statically link all my Linux CLI tools against musl for this reason. Or use Nix.
Sharlin 1y ago
Sure, but Rust specifically uses static linking for everything but the very basics (ie. libc) in order to avoid the DLL hell.
craftkiller 1y ago
Don't let your dreams be dreams $ wget 'https://github.com/BurntSushi/ripgrep/releases/download/14.1.1/ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz' $ tar -xvf 'ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz' $ ldd ripgrep-14.1.1-x86_64-unknown-linux-musl/rg ldd (0x7f1dcb927000) $ file ripgrep-14.1.1-x86_64-unknown-linux-musl/rg ripgrep-14.1.1-x86_64-unknown-linux-musl/rg: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, stripped
- 3836293648 1y ago
  Which only works on linux. No other OS allows static binaries, you always need to link to libc for syscalls.
  - craftkiller 1y ago
    Also works on FreeBSD. FreeBSD maintains ABI compatibility within each major version (so 14.0 is compatible with 14.1, 14.2, and 14.3 but not 15.0): You also can install compatibility packages that make binaries compiled for older major versions run on newer major versions. $ pkg install git rust $ git clone https://github.com/BurntSushi/ripgrep.git $ cd ripgrep $ RUSTFLAGS='-C target-feature=+crt-static' cargo build --release $ ldd target/release/rg ldd: target/release/rg: not a dynamic ELF executable $ file target/release/rg target/release/rg: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 14.3, FreeBSD-style, with debug_info, not stripped
  - exe34 1y ago
    try cosmopolitan!
    - 3836293648 1y ago
      Cosmopolitan isn't statically linked, it's just a hack that works on all systems, dynamically linking on windows and macos (I think with a statically linked custom dynamic linker?)
deleted 1y ago
[deleted]
1718627440 1y ago
> The worst is compiling a C program with a compiler that uses a more recent libc than is installed on the installation host. This is only a problem, when the program USES a symbol that was only introduced in the newer libc. In other words, when the program made a choice to deliberately need that newer symbol.

dboon 1y ago

That’s the first rule anyone writing portable binaries learns. Compile against an old libc, and stuff tends to just work.

delta_p_delta_x 1y ago
> Compile against an old libc This clause is abstracting away a ton of work. If you want to compile the latest LLVM and get 'portable C++26', you need to bootstrap everything, including CMake from that old-hat libc on some ancient distro like CentOS 6 or Ubuntu 12.04. I've said it before, I'll say it again: the Linux kernel may maintain ABI compatibility, but the fact that GNU libc breaks it anyway makes it a moot point. It is a pain to target older Linux with a newer distro, which is by far the most common development use case.
- dboon 1y ago
  Definitely, and I know this sounds like ignoring the problem, but in my experience the best solution is to just not use the bleeding edge. Write your code such that you can load it onto (for example) the oldest supported Ubuntu and compile cleanly and you’ll have virtually zero problems. Again, I know that if your goal is to truly ship something written in e.g. C++26 portably then it’s a huge pain. But as someone who writes plain C and very much enjoys it, I think it’s better to skip this class of problem.
  - delta_p_delta_x 1y ago
    > I think it’s better to skip this class of problem. I'll keep my templates, smart pointers, concepts, RAII, and now reflection, thanks. C and its macros are good for compile times but nothing much else. Programming in C feels like banging rocks together.
    - dboon 1y ago
      Agree to disagree, then! Templates, smart pointers, and RAII have cost me far, far more than they’ve paid me back. You should write whatever feels good to you.
      - delta_p_delta_x 1y ago
        Happy to. If I may, I have an analogy: C feels a little like survival mode in Minecraft; you have a set of very simple abstractions, a relatively simple language, with which one can build the world (and in many cases, we have). C++ feels like a complex city builder, with lots of tools, designs, and paradigms available, but also allows one to screw up in bigger ways.

bschwindHN 1y ago

Yes but I've never had a native tool fail on a missing libc. I've had several Python tools and JS tools fail on missing the right version of their interpreter. Even on the right interpreter version Python tools frequently shit the bed because they're so fragile.

mjevans 1y ago
I have. During system upgrades, usually along unsupported paths. If you're ever living dangerously, bring along busybox-static. It might not be the best, but you'll thank yourself later.

sestep 1y ago

I statically link all my Linux CLI tools against musl for this reason. Or use Nix.

Sharlin 1y ago

Sure, but Rust specifically uses static linking for everything but the very basics (ie. libc) in order to avoid the DLL hell.

craftkiller 1y ago

Don't let your dreams be dreams $ wget 'https://github.com/BurntSushi/ripgrep/releases/download/14.1.1/ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz' $ tar -xvf 'ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz' $ ldd ripgrep-14.1.1-x86_64-unknown-linux-musl/rg ldd (0x7f1dcb927000) $ file ripgrep-14.1.1-x86_64-unknown-linux-musl/rg ripgrep-14.1.1-x86_64-unknown-linux-musl/rg: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, stripped

3836293648 1y ago
Which only works on linux. No other OS allows static binaries, you always need to link to libc for syscalls.
- craftkiller 1y ago
  Also works on FreeBSD. FreeBSD maintains ABI compatibility within each major version (so 14.0 is compatible with 14.1, 14.2, and 14.3 but not 15.0): You also can install compatibility packages that make binaries compiled for older major versions run on newer major versions. $ pkg install git rust $ git clone https://github.com/BurntSushi/ripgrep.git $ cd ripgrep $ RUSTFLAGS='-C target-feature=+crt-static' cargo build --release $ ldd target/release/rg ldd: target/release/rg: not a dynamic ELF executable $ file target/release/rg target/release/rg: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 14.3, FreeBSD-style, with debug_info, not stripped
- exe34 1y ago
  try cosmopolitan!
  - 3836293648 1y ago
    Cosmopolitan isn't statically linked, it's just a hack that works on all systems, dynamically linking on windows and macos (I think with a statically linked custom dynamic linker?)

deleted 1y ago

[deleted]

1718627440 1y ago

> The worst is compiling a C program with a compiler that uses a more recent libc than is installed on the installation host. This is only a problem, when the program USES a symbol that was only introduced in the newer libc. In other words, when the program made a choice to deliberately need that newer symbol.