I personally agree that there should be a stable ABI, however I'm not sure
it should the the standard library that does it. I'm working on one myself
to go cross-platform with, where the only binaries you directly deal with
are the *.o and *.a files. The rest is handled by a launcher that runs make
with variables like MAIN_O, LIBMAIN_O, PAW_ABI, NPAW_ABI, etc to help link
the objects into the native executable/library format. I even figured out
how to implement mremap on windows despite it's annoying map handles
(requires something like (HANDLE*)vmcommit( map_addr - pagesize )[0] =
map_handle). Now where near ready for use or even compiling but perhaps
when it's ready people who need a standardised ABI would require external
software to communicate with theirs via that. The standard library would no
longer need to maintain a stable ABI at that point since it would act as
the experimental grounds for developing tech while my library/launcher pair
would follow on behind exposing the best features developed in the standard
library.

On Fri, 12 Jul 2024 at 11:47, Hans via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 11/07/2024 22:28, Tiago Freire wrote:
> > If you are talking about "static libraries", a library produced by a
> particular compiler vendor can not be linked with a different compiler
> vendor.
> > The file formats are not the same, the concepts they use differ, they
> just don't talk the same language. Even libraries produced by the same
> compiler vendor on different versions are not even guaranteed to work.
>
> This is incorrect: static library formats are well-defined, and you can
> cross-link between compilers (at least, on the same platform).
>
> > Dynamic libraries have a similar problem, if two compiler vendors can
> not agree on an implementation to use (not to mention name mangling rules),
> how do you expect them to agree on adopting a consistent numerical
> definition that describes the particular implementation adopted?
>
> This is also incorrect: dynamic library formats are also well-defined,
> and you can open libraries from different compilers and different
> languages (again, on the same platform).
>
> We have extern "C" to disable name mangling, but that's a choice by the
> library author. Library authors that care about interoperability with
> other languages will want to disable name mangling and not throw any
> exceptions, but this is not part of the proposal.
>
> > I personally think that concerns of breaking ABI are often unwarranted,
> and that the committee is being overly conservative about not breaking ABI,
> and that this is holding the language back!
>
> So do I, but we're not in charge. My proposal is my next best choice.
>
> I have personally had to deal with binary-only libraries using unstable
> classes in public interfaces multiple times. Each time it was dramatic,
> getting vendors to upgrade their compilers (and undoubtedly causing
> grief to their other customers in the process). We need a better solution.
>
>
> Hans Guijt
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>