3 ms·

Speedy convenience beats absolute correctness anyday. Humans are not immortal and have finite amount of time for life and work. If convenience didn't matter, we

by lenkite 7mo ago

Speedy convenience beats absolute correctness anyday. Humans are not immortal and have finite amount of time for life and work. If convenience didn't matter, we would all still be coding in assembly or toggling hardware switches.

jjmarr 7mo ago
C++ builds are extremely slow because they are not correct. I'm doing a migration of a large codebase from local builds to remote execution and I constantly have bugs with mystery shared library dependencies implicitly pulled from the environment. This is extremely tricky because if you run an executable without its shared library, you get "file not found" with no explanation. Even AI doesn't understand this error.
- mgaunard 7mo ago
  The dynamic linker can clearly tell you where it looks for files and in which order, and where it finds them if it does. You can also very easily harden this if you somehow don't want to capture libraries from outside certain paths. You can even build the compiler in such a way that every binary it produces has a built-in RPATH if you want to force certain locations.
  - jjmarr 7mo ago
    That is what I'm doing so I can get distributed builds working. It sucks and has taken me days of work.
    - mgaunard 7mo ago
      It's pretty simple and works reliably as specified. I can only infer that your lack of familiarity was what made it take so long. Rebuilding GCC with specs does take forever, and building GCC is in general quite painful, but you could also use patchelf to modify the binary after the fact (which is what a lot of build systems do).
      - jjmarr 7mo ago
        > I can only infer that your lack of familiarity was what made it take so long Pretty much. Trying to convert an existing build that doesn't explicitly declare object dependencies is painful. Rust does it properly by default. For example, I'm discovering our clang toolchain has a transitive dependency on a gcc toolchain.
        mgaunard 7mo ago
        Clang cannot bootstrap in the same way GCC can; you need GCC (or another clang) to build it. You can obviously build it twice to have it be built by itself (bear in mind some of the clang components already do this, because they have to be built by clang). In general though, a clang install will still depend on libstdc++, libgcc, GCC crtbegin.o and binutils (at least on Linux), which is typically why it will refer to a specific GCC install even after being built. There are of course ways to use clang without any GCC runtime, but that's more involved and non-standard (unless you're on Mac). And there is also the libc dependency (and all sysroot aspects in general) and while that is usually considered completely separate from GCC, the filesystem location and how it is found is often tied to how GCC is configured.
morning-coffee 7mo ago
The Mars Polar Lander and Mars Climate Orbiter missions would beg to differ. (And "absolute" or other adjectives don't qualify "correctness"... it simply is or isn't.)

by lenkite 7mo ago

jjmarr 7mo ago

C++ builds are extremely slow because they are not correct. I'm doing a migration of a large codebase from local builds to remote execution and I constantly have bugs with mystery shared library dependencies implicitly pulled from the environment. This is extremely tricky because if you run an executable without its shared library, you get "file not found" with no explanation. Even AI doesn't understand this error.

mgaunard 7mo ago
The dynamic linker can clearly tell you where it looks for files and in which order, and where it finds them if it does. You can also very easily harden this if you somehow don't want to capture libraries from outside certain paths. You can even build the compiler in such a way that every binary it produces has a built-in RPATH if you want to force certain locations.
- jjmarr 7mo ago
  That is what I'm doing so I can get distributed builds working. It sucks and has taken me days of work.
  - mgaunard 7mo ago
    It's pretty simple and works reliably as specified. I can only infer that your lack of familiarity was what made it take so long. Rebuilding GCC with specs does take forever, and building GCC is in general quite painful, but you could also use patchelf to modify the binary after the fact (which is what a lot of build systems do).
    - jjmarr 7mo ago
      > I can only infer that your lack of familiarity was what made it take so long Pretty much. Trying to convert an existing build that doesn't explicitly declare object dependencies is painful. Rust does it properly by default. For example, I'm discovering our clang toolchain has a transitive dependency on a gcc toolchain.
      - mgaunard 7mo ago
        Clang cannot bootstrap in the same way GCC can; you need GCC (or another clang) to build it. You can obviously build it twice to have it be built by itself (bear in mind some of the clang components already do this, because they have to be built by clang). In general though, a clang install will still depend on libstdc++, libgcc, GCC crtbegin.o and binutils (at least on Linux), which is typically why it will refer to a specific GCC install even after being built. There are of course ways to use clang without any GCC runtime, but that's more involved and non-standard (unless you're on Mac). And there is also the libc dependency (and all sysroot aspects in general) and while that is usually considered completely separate from GCC, the filesystem location and how it is found is often tied to how GCC is configured.

morning-coffee 7mo ago

The Mars Polar Lander and Mars Climate Orbiter missions would beg to differ. (And "absolute" or other adjectives don't qualify "correctness"... it simply is or isn't.)