4 ms·
It was never really possible to compile a library with one C compiler and expect it to link against code produced by another C compiler, unless both compilers h
by flohofwoe 2mo ago
It was never really possible to compile a library with one C compiler and expect it to link against code produced by another C compiler, unless both compilers happen to agree on specific ABI details that are either defined outside the C standard or not at all.
And to be honest, this sort of compiler-specific ABI interoperability is a non-problem that doesn't need solving, it's at most relevant for software developers of closed source libraries who distribute the libraries as precompiled blobs. But those must be stamped out for different target-triples anyway.
- aw1621107 2mo agoI'm... a bit confused? I wasn't thinking about inter-compiler interop at all.
- flohofwoe 2mo agoCompiler interoperability is the only ABI related problem area that's remotely in the scope for the C standard, but IMHO not even that (it's really not a problem that needs solving). Ultimately any ABI discussions need to happen between CPU and OS vendors, compiler toolchains implement whatever comes out of those discussions.
- uecker 2mo agoHuh, compiler interoperability is extremely useful. It usually works by ABI groups defining a common ABI for each architecture and compilers then following these ABIs (although not required a compilers that does not is poor)
- flohofwoe 2mo agoIt's useful for closed-source developers who want to sell their libraries as precompiled binary blobs for static linking, but as soon as MSVC is involved that idea of "one library for different compilers" is out the window anyway ;) For areas like application plugins via DLLs it's the OS ABI that matters.
- uecker 2mo agoIt is also relevant for dynamic linking on all Linux binary distributions.
- flohofwoe 2mo agoHmm yeah ok, because Linux distros and glibc apparently never cared about defining a proper system ABI outside of 'whatever gcc happens to do'.
- uecker 2mo agoI don't understand this comment. There are well-defined ABIs for many platforms. Sometimes there is a defacto ABI defined by the first compiler supporting this platform, but generally there ABI groups that agree on a common ABI for each architecture. This then allows code compiled by different compiler to be linked against common libraries - not just glibc. I can compile my projects with either clang, gcc, or some other compiler and link statically or dynamically against all the same libraries distributed by my distribution regardless of which compiler was used to compile them. This is extremely useful.
- aw1621107 2mo ago> Compiler interoperability is the only ABI related problem area that's remotely in the scope for the C standard idk, given how ABI impacts the evolution of C I think it's not unreasonable to provide a mechanism by which ABI can be evolved even if it's not specifically for compiler interop. > Ultimately any ABI discussions need to happen between CPU and OS vendors, compiler toolchains implement whatever comes out of those discussions. I think part of the article author's reasoning for proposing this feature is that toolchains have implemented something like this feature to try to address ABI issues and that the rest of the ecosystem could benefit from a similar technique.
- dwattttt 2mo ago> inter-compiler interop Inter-compiler interop is also in play when the two compilers are the same one at different versions, or even potentially flags.