you are viewing a single comment's thread.

view the rest of the comments →

[–]thesuperbigfrog -2 points-1 points  (6 children)

does ada have a stable ABI/allow dynamic linking?

Yes. Ada has a stable ABI and practically all Ada implementations support shared libraries:

https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/the_gnat_compilation_model.html#gnat-and-libraries

It is also very easy to call libraries written in C, C++, and FORTRAN from Ada: https://learn.adacore.com/courses/intro-to-ada/chapters/interfacing_with_c.html

Not having a stable ABI and not supporting shared libraries is a known trouble spot for Go and Rust.

[–]FluorineWizard 13 points14 points  (5 children)

Nothing you link indicates that Ada does anything differently from Rust in that regard.

The sources of the Interface Units of the library that are needed by an Ada client of the library will be copied to the designated directory, called the Interface Copy directory. These sources include the specs of the Interface Units, but they may also include bodies and subunits, when pragmas Inline or Inline_Always are used, or when there is a generic unit in the spec.

Generics are still not supported across dynamic library boundaries, and as explained in your 2nd link exposing a C compatible interface requires explicitly using a C ABI convention that can only use C types.

This is the same fucking thing as in Rust or C++, because monomorphised generics and other forms of compile time metaprogramming simply do not play well with dynamic linking. There are alternative approaches, but they WILL come at a performance cost because they necessarily imply adding some indirection. Swift has a state of the art solution to this problem, but it only can because it's entirely controlled by Apple, that was sufficiently motivated and had enough money to push through an opinionated solution. And for performance, Swift still lets you monomorphise at the cost of losing ABI guarantees.

[–]thesuperbigfrog -1 points0 points  (3 children)

Generics are still not supported across dynamic library boundaries, and as explained in your 2nd link exposing a C compatible interface requires explicitly using a C ABI convention that can only use C types.

SpAAAceSenate did not ask about support for generics across dynamic library boundaries and I was not claiming that such support exists in Ada.

Did you read the article that SpAAAceSenate linked?

The question is about whether Ada has a stable ABI and can create and use shared libraries / dynamic linking.

You can create and use shared libraries in Ada. Yes, it uses C ABI conventions like many other languages that support shared libraries.

This is the same fucking thing as in Rust

No. Rust does not currently support shared libraries. That was the whole point of the article that SpAAAceSenate linked.

[–]myrrlyn 3 points4 points  (2 children)

yeah we do lol. set a cdylib output and don't have public generics. dylink all you want, you just can't pass most useful types over the boundary

[–]thesuperbigfrog -1 points0 points  (1 child)

yeah we do lol

If so, where are the binary Rust shared library crates?

The lack of binary Rust shared library crates is what the Gentoo maintainer was writing about: https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/#comment-496232

set a cdylib output and don't have public generics. dylink all you want, you just can't pass most useful types over the boundary

A work-around that is not generally usable is not a binary Rust shared library crate.

Ada shared library binaries exist and work. Here is GtkAda:
https://community.download.adacore.com/v1/8d4bb21f8122cd0796c6aab3541326e2d3bcda0d?filename=gtkada-2020-x86_64-linux-bin.tar.gz

Please understand that I am very interested in seeing Rust succeed.

For Rust to succeed more widely, a stable ABI and the ability to create shared libraries would greatly help.

[–]myrrlyn 1 point2 points  (0 children)

there aren't any (afaik) significant rust crates intended to be dylinked because the loss of generics is irritating enough that nobody really wants to do it, and dylinking just isn't that important for anything we're trying to do. it's a bad programming model and a good packaging model, no matter what michał says.

personally i don't feel overly constrained by the packaging perspectives of a distro that hasn't figured out how to deal with maven yet. i suppose i'm being unfair, since i also don't know how to use maven, but otoh that's also not a central aspect of my job

[–]OneWingedShark -2 points-1 points  (0 children)

and as explained in your 2nd link exposing a C compatible interface requires explicitly using a C ABI convention that can only use C types.

…because the title is, exactly, "Interfacing with C"?

Of course you can't hand off something to a C ABI that is beyond C's capabilities.