4 ms·

My personal opinion on the whole thing is that the decision to not standardize the ABI was correct, because it has been easy since forever to define a static bi

My personal opinion on the whole thing is that the decision to not standardize the ABI was correct, because it has been easy since forever to define a static binary interface, if you (the developer) choose to do so. See OpenGL, for example. If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. Unless, of course, you're using undocumented APIs. And even then, you can solve all those issues by statically linking against your dependencies. In 20+ years of building distributed C++ systems I've just never seen inter-compiler ABI compatibility being an issue in practice.

bluGill 4y ago
Intra compiler abi is the problem. I have to support plugins someone else built with GCC old. Break abi and I can't upgrade my code.
- fxtentacle 4y ago
  Then it seems like your plugin API was not specified well. extern "C" and ABI will stay the same, no matter which compiler is used.
  - bluGill 4y ago
    Hindsight is 20/20. Though I will say that management at the time hid this aspect from engineers, and so we didn't know about the risk until it was too late .
CoastalCoder 4y ago
> If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. I somewhat agree with the parent's point if we broaden "compiler" to include all of the ecosystem tools that care about the ABI. E.g., debuggers really benefit from knowing about the ABIs being used.
- fxtentacle 4y ago
  Yes, but debuggers are useless without the source code. And if you have the latter, re-compiling to match the new ABI is easy.
  - CoastalCoder 4y ago
    > Yes, but debuggers are useless without the source code. That's not true in my experience. Sometimes it's helpful to see the call stack even without symbols. And sometimes there's benefit in debugging at the disassembly level, even without access to the source code. > And if you have the latter, re-compiling to match the new ABI is easy. I think we're talking about the scenario where the code was already compiled to the new ABI, but the debugger doesn't understand the new ABI. A few thoughts on this: 1) Depending on circumstances, even if you have access to the source code, you might not be able to recompile it for the sake of better debugging. 2) If the code is linked against libraries that use the new ABI, or uses compiler features that require the new ABI, you can't necessarily produce a build that uses only the old ABI.

bluGill 4y ago

Intra compiler abi is the problem. I have to support plugins someone else built with GCC old. Break abi and I can't upgrade my code.

fxtentacle 4y ago
Then it seems like your plugin API was not specified well. extern "C" and ABI will stay the same, no matter which compiler is used.
- bluGill 4y ago
  Hindsight is 20/20. Though I will say that management at the time hid this aspect from engineers, and so we didn't know about the risk until it was too late .

CoastalCoder 4y ago

> If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. I somewhat agree with the parent's point if we broaden "compiler" to include all of the ecosystem tools that care about the ABI. E.g., debuggers really benefit from knowing about the ABIs being used.

fxtentacle 4y ago
Yes, but debuggers are useless without the source code. And if you have the latter, re-compiling to match the new ABI is easy.
- CoastalCoder 4y ago
  > Yes, but debuggers are useless without the source code. That's not true in my experience. Sometimes it's helpful to see the call stack even without symbols. And sometimes there's benefit in debugging at the disassembly level, even without access to the source code. > And if you have the latter, re-compiling to match the new ABI is easy. I think we're talking about the scenario where the code was already compiled to the new ABI, but the debugger doesn't understand the new ABI. A few thoughts on this: 1) Depending on circumstances, even if you have access to the source code, you might not be able to recompile it for the sake of better debugging. 2) If the code is linked against libraries that use the new ABI, or uses compiler features that require the new ABI, you can't necessarily produce a build that uses only the old ABI.