Re: gnat-3.2 transition plan

[Miah Gregory <mace@darksilence.net>]

In message <[🔎] 15969.58392.276921.835885@gargle.gargle.HOWL>
          Matthias Klose <doko@cs.tu-berlin.de> wrote:

> Florian Weimer writes:

> > Please drop shared library support altogether.  It is currently not
> > worth the trouble.  GNAT ABIs change from version to version, and the
> > run-time library can be built only with the corresponding version of
> > the compiler.  This means that a lot of work is required each time a
> > new GNAT version is released.

> will do for the next upload.

This concerns me a little. It seems to my untrained eye that this change
would mean that we're sacrificing large amounts of space in packages
compiled with GNAT, just to save rebuilding those packages when a new
version of GNAT is uploaded? Given that ACT releases aren't exactly daily,
is this really the right solution for the problem?

As an example, Steven Murdoch sent me some statistics from compiling a very
simple 'hello world' program:

-snip-
with Ada.Text_IO; use Ada.Text_IO;

procedure Hello_World is

begin
   Put_Line("Hello, World!");
end Hello_World;
-snip-

Dynamic compiled with: gnatmake hello_world.adb
Static compiled with:  gnatmake hello_world.adb -bargs -static

Executable size:
.______________._______________________._______________________.
|              |         Dynamic       |         Static        |
| Program      | Unstripped | Stripped | Unstripped | Stripped |
|--------------+------------+----------+------------+----------|
| hello world  | 11kb       | 6.2kb    | 540kb      | 113kb    |
| another test | 75kb       | 55kb     | 1017kb     | 252kb    |
| gvd          | 6.3mb      | 2094kb   | 6.6mb      | 2309kb   |
`--------------+------------+----------+------------+----------'

So, for big executables, changing to static isn't going to make a great
deal of difference, but for smaller programs, this could well mean a
significant increase in binary size (incidentally, gvd is already being
statically linked).

Another, non-technical reason for sticking with shared libraries by default,
is that it'll take us back to the age old "but ada produces massive
binaries, so it must be crap" argument, thereby discouraging some from
using it.

Just my 2p, though.

-- 
Miah Gregory