Prev: gnatmake: "ada.numerics.real_arrays" is not a predefined libraryunit
Next: comp.lang.ada charter
From: Samuel Tardieu on 21 Apr 2008 13:01
>>>>> "Ludovic" == Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes:

Ludovic> It's been in the back of my mind for a few months that I
Ludovic> should build a shared libgnala.so, package it separately from
Ludovic> libgnat-4.3.so, and arrange for it to depend on
Ludovic> lapack. Patches to that effect are, of course, welcome and
Ludovic> will be gratefully accepted.

Maybe we can work out the shared/static issue in GCC sources. Patches
welcome too there :)

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.

Sam
--
Samuel Tardieu -- sam(a)rfc1149.net -- http://www.rfc1149.net/
From: Ludovic Brenta on 21 Apr 2008 15:35
Samuel Tardieu writes:
>>>>>> "Ludovic" == Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes:
>
> Ludovic> It's been in the back of my mind for a few months that I
> Ludovic> should build a shared libgnala.so, package it separately from
> Ludovic> libgnat-4.3.so, and arrange for it to depend on
> Ludovic> lapack. Patches to that effect are, of course, welcome and
> Ludovic> will be gratefully accepted.
>
> Maybe we can work out the shared/static issue in GCC sources. Patches
> welcome too there :)

Definitely; this is an area where all distributions would benefit.
However, Debian is a bit peculiar since it patches the library
building process (in gcc/ada/Makefile.in) heavily so as to build both
the zero-cost and setjump/longjump versions of the library. So, if I
produce a patch, someone will have to adjust it for upstream 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.

"Suggests" or "Recommends" is not good enough because it would foil
the automatic dependency management Debian is renowned for. The
proper solution is to place libgnala.so in a separate package
(suggested or recommended by gnat-4.3) but that Depends on
(i.e. requires) lapack to be installed. This way, if someone builds a
package where they use Annex G, their package will automatically
depend on libgnala.so and, indirectly, on lapack. With your proposal,
this would not happen as lapack would be only recommended.

--
Ludovic Brenta.
From: Samuel Tardieu on 21 Apr 2008 16:35
>>>>> "Ludovic" == Ludovic Brenta <ludovic(a)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.

>> 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.

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 :)

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.

Sam
--
Samuel Tardieu -- sam(a)rfc1149.net -- http://www.rfc1149.net/
From: Ludovic Brenta on 21 Apr 2008 17:05
Samuel Tardieu <sam(a)rfc1149.net> writes:
>>>>>> "Ludovic" == Ludovic Brenta <ludovic(a)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.
From: Samuel Tardieu on 22 Apr 2008 06:46
>>>>> "Jerry" == Jerry <lanceboyle(a)qwest.net> writes:

Jerry> The upshot is that the file i-forbla.adb is edited to comment
Jerry> out one line, so that after the edit we see this:

Jerry> -- pragma Linker_Options ("-lgnalasup")

Yes, I changed the GCC sources this morning to reference LAPACK and
BLAS directly by default instead of gnalasup which is a repackaging of
those libraries done by AdaCore.

Sam
--
Samuel Tardieu -- sam(a)rfc1149.net -- http://www.rfc1149.net/
 |  Next  |  Last
Pages: 1 2
Prev: gnatmake: "ada.numerics.real_arrays" is not a predefined libraryunit
Next: comp.lang.ada charter