4 ms·

The solution here is to simply not use dynamic linking for anything outside glibc and openssl. If your program is statically linked, or if each program ships al

The solution here is to simply not use dynamic linking for anything outside glibc and openssl. If your program is statically linked, or if each program ships all the dynamic libraries it links against, this compatibility problem disappears.

mlyle 5y ago
Static linking doesn't fix it. You still need to know how every library you use was built, and choose the same setting.
- howinteresting 5y ago
  I'm assuming that you're also building all your dependent libraries as part of your build process, as is common with languages like Rust. Closed source libraries are somewhat out of scope when talking about Linux distributions, though you can always ask the vendor to provide you a 64-bit compatible library.
  - WJW 5y ago
    > though you can always ask the vendor to provide you a 64-bit compatible library This is not always true, as the vendor may have disappeared and can no longer provide new versions of the library for any reason. Though, if you knowingly have such a black box in your code and willingly keep running with it until 2038 then you kinda deserve what is coming.
  - mlyle 5y ago
    Then it's not a distinction between dynamic linking and static linking. It's a distinction of "only link against things you yourself build and ship". It's nothing to do with closed or open source. I don't want to build a very big world, and ship a huge amount of binary code that can be found in distributions, to make a 2038-safe app.
    - howinteresting 5y ago
      It's not that big a world. And ststic linking in particular opens up a ton of other opportunities, such as monomorphization.
jandrese 5y ago
But then you have to audit every single application and its libraries for latent Y2038 problems. It doesn't really save you anything except making it more difficult to track down problem applications. They'll continue pretending nothing is wrong until the drop dead date.

mlyle 5y ago

Static linking doesn't fix it. You still need to know how every library you use was built, and choose the same setting.

howinteresting 5y ago
I'm assuming that you're also building all your dependent libraries as part of your build process, as is common with languages like Rust. Closed source libraries are somewhat out of scope when talking about Linux distributions, though you can always ask the vendor to provide you a 64-bit compatible library.
- WJW 5y ago
  > though you can always ask the vendor to provide you a 64-bit compatible library This is not always true, as the vendor may have disappeared and can no longer provide new versions of the library for any reason. Though, if you knowingly have such a black box in your code and willingly keep running with it until 2038 then you kinda deserve what is coming.
- mlyle 5y ago
  Then it's not a distinction between dynamic linking and static linking. It's a distinction of "only link against things you yourself build and ship". It's nothing to do with closed or open source. I don't want to build a very big world, and ship a huge amount of binary code that can be found in distributions, to make a 2038-safe app.
  - howinteresting 5y ago
    It's not that big a world. And ststic linking in particular opens up a ton of other opportunities, such as monomorphization.

jandrese 5y ago

But then you have to audit every single application and its libraries for latent Y2038 problems. It doesn't really save you anything except making it more difficult to track down problem applications. They'll continue pretending nothing is wrong until the drop dead date.