Re: gnatmake: "ada.numerics.real_arrays" is not a predefined library unit

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Samuel Tardieu <sam@rfc1149.net> writes:
>>>>>> "Ludovic" == Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>
> Ludovic> Definitely; this is an area where all distributions would
> Ludovic> benefit.  However, Debian is a bit peculiar since it patches
> Ludovic> the library building process (in gcc/ada/Makefile.in) heavily
> Ludovic> so as to build both the zero-cost and setjump/longjump
> Ludovic> versions of the library.  So, if I produce a patch, someone
> Ludovic> will have to adjust it for upstream GCC.
>
> In fact, I've had a look and I'm not sure it is interesting to make a
> shared version of libgnala at all. It contains mostly generics.

That's a thought.  In that case, it would be nice to investigate how
easy it is for the programmer to link with libgnala.a and lapack.  For
example, libgnala.a is currently installed in
/usr/lib/gcc/x86_64-linux-gnu/4.3/rts-native/adalib/ without any
symlink to it from /usr/lib, and so linking with it may require ugly
linker options (ugly because they depend on the OS and version of
GCC).

>>> Concerning the distribution, why separate libgnala.so from libgnat?
>>> You don't need a dependency on lapack/blas, only a "suggests" or
>>> "recommends" if people want to build applications requiring annex g
>>> support. As far as compiled applications are concerned, the
>>> lapack/blas dependency will be recored as part of a regular Debian
>>> dependency.
>
> Ludovic> "Suggests" or "Recommends" is not good enough because it
> Ludovic> would foil the automatic dependency management Debian is
> Ludovic> renowned for.  The proper solution is to place libgnala.so in
> Ludovic> a separate package (suggested or recommended by gnat-4.3) but
> Ludovic> that Depends on (i.e. requires) lapack to be installed.
>
> What is the difference between:
>
>   - gnat bundles libgnala with gnat, and recommends lapack
>   - gnat recommends libgnala, which depends on lapack (your recommendation)
>
> ?
>
> In both configurations, someone wanting to use GNAT with Annex G will
> have to install a package on which GNAT does not depend, be it
> libgnala or lapack.

Yes indeed.

> Ludovic> This way, if someone builds a package where they use Annex G,
> Ludovic> their package will automatically depend on libgnala.so and,
> Ludovic> indirectly, on lapack.  With your proposal, this would not
> Ludovic> happen as lapack would be only recommended.
>
> With my proposal, someone building a system using Annex G would get a
> "depends" on lapack through the shared library. With yours, they would
> get a "depends" on libgnala.so which has in turn a "depends" on
> lapack.
>
> I fail to see the difference, except maybe a matter of taste :)

Now I see what you mean, i.e. the lapack shared library will cause the
new package to depend on the lapack package.  I agree that it doesn't
make much of a difference in the end.  However, it is still necessary
that whatever package contains a (now hypothetical) libgnala.so depend
on lapack.  Good taste, as you put it, requires that shared library
dependencies be captured in the package system.

> Anyway, I've started investigating the "libgnalasup" issue. This
> library is referenced by i-forbla.adb, but doesn't seem to be
> distributed. Replacing it with "liblapack" and "libblas" may be
> enough.

Cool!

-- 
Ludovic Brenta.