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

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

[Reinert Korsnes]

Hello,

My linux system (opensuse 10.3 updated) does not
find "ada.numerics.real_arrays.  Should it ?

Details:
--------
I tried to compile a program starting like this:

with Text_IO;
use  Text_IO;
with   Ada.Numerics,Ada.Numerics.Real_Arrays;
with   Ada.Numerics.Generic_Elementary_Functions;
procedure test2 is

...


I used the command:

gnatmake -gnat05 test2.adb

Then I get the error message:

test2.adb:3:21: "ada.numerics.real_arrays" is not a predefined library unit
gnatmake: "test2.adb" compilation error

Is there any hope for me to use "Ada.Numerics.Real.Arrays" ?

reinert

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

[Georg Bauhaus]

Reinert Korsnes schrieb:
> Hello,
> 
> My linux system (opensuse 10.3 updated) does not
> find "ada.numerics.real_arrays.  Should it ?
> 
> test2.adb:3:21: "ada.numerics.real_arrays" is not a predefined library unit
> gnatmake: "test2.adb" compilation error
> 
> Is there any hope for me to use "Ada.Numerics.Real.Arrays" ?

Looks like SuSE is still shipping an older compiler.
However, there does seem to be a GNAT GPL 2007 RPM.

Also, I'd consider getting Debian (or Ubuntu); runs nicely
on a virtual machine in case you need SuSE to be you main
OS for some reason.


For SuSE, another starting point is:
http://gnuada.sourceforge.net/pmwiki.php/Install/SuSE

$ gnatkr Ada.Numerics.Real_Arrays.ads
a-nurear.ads
$ locate a-nurear.ads
/usr/local/ada-4.3/lib/gcc/i686-apple-darwin8/4.3.0/adainclude/a-nurear.ads

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

[Ludovic Brenta]

Georg Bauhaus wrote:
> Also, I'd consider getting Debian (or Ubuntu);

Thanks; I really appreciate this but in this particular area, Debian
is probably no better than any other distribution. You see, the GNAT
implementation of Annex G is, essentially, a binding to LAPACK. The
relevant units (Ada.Numerics.*) are in a static library called
libgnala.a (GNAT Linear Algebra) which is separate from libgnat.a.
Moreover, the upstream Makefile does not build a shared version of
libgnala.a.

So, if someone wants to use Annex G you must:
- build with "gnatmake -static"
- link with libgnala.a
- link with LAPACK

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

To the OP: this libgnala.a only appeared in GCC 4.3 released in
January 2008. If SuSE ships anything older than that, you must upgrade
your compiler if you want to take advantage of Annex G.

--
Ludovic Brenta.

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

[Samuel Tardieu]

>>>>> "Ludovic" == Ludovic Brenta <ludovic@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@rfc1149.net -- http://www.rfc1149.net/

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

[Ludovic Brenta]

Samuel Tardieu writes:
>>>>>> "Ludovic" == Ludovic Brenta <ludovic@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.

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

[Samuel Tardieu]

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

>> 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@rfc1149.net -- http://www.rfc1149.net/

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

[Ludovic Brenta]

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.

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

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

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

FWIW, this

$ gnatmake hello \
  -largs -lgnala -L/Developer/SDKs/MacOSX10.4u.sdk/usr/lib -lblas -llapack 

_nearly_ works with an unedited i-forbla.adb GNAT-GPL-2007 on Mac OS X Tiger;

opt/gnat-gpl-2007-dynamic/lib/gcc/powerpc-apple-darwin8.11.0/4.1.3/adalib//libgnala.a(a-nlcoar.o) reference to undefined _zdot_

So the ugly linker options involved finding libblas and liblapack only.

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

[Jerry]

On Apr 21, 4:34 am, Reinert Korsnes <a...@b.no> wrote:
> Hello,
>
> My linux system (opensuse 10.3 updated) does not
> find "ada.numerics.real_arrays.  Should it ?
>
> Details:
> --------
> I tried to compile a program starting like this:
>
> with Text_IO;
> use  Text_IO;
> with   Ada.Numerics,Ada.Numerics.Real_Arrays;
> with   Ada.Numerics.Generic_Elementary_Functions;
> procedure test2 is
>
> ...
>
> I used the command:
>
> gnatmake -gnat05 test2.adb
>
> Then I get the error message:
>
> test2.adb:3:21: "ada.numerics.real_arrays" is not a predefined library unit
> gnatmake: "test2.adb" compilation error
>
> Is there any hope for me to use "Ada.Numerics.Real.Arrays" ?
>
> reinert

I don't want to confuse the discussion here, but the OS X ada list
(www.macada.org) has been discussing this lately, (as well as
December, 2007 if you're inclined to dig through archives).

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

--  pragma Linker_Options ("-lgnalasup")

All I did then was to compile a "hello" program using -a that with-ed
Ada.Numerics.Long_Real_Arrays and Ada.Numerics.Long_Complex_Arrays,
then copied the new .o and .ali to the proper Ada library directory. I
can supply more details if needed. Also, I don't pretend to understand
why this works.

Incidentally, BLAS and LAPACK, both Fortran and C versions, come pre-
installed on OS X so linking to them is pretty trivial.

Jerry

P.S. Sorry if this post appears twice. My last two posts did, and I'm
blaming it on my browser.

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

[Samuel Tardieu]

>>>>> "Jerry" == Jerry  <lanceboyle@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@rfc1149.net -- http://www.rfc1149.net/

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

[Ludovic Brenta]

Samuel Tardieu wrote:
> 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.

This patch will make it into the next upload of gnat-4.3. However,
since I uploaded a new gnat-4.3 just yesterday evening, I'll wait a
couple of weeks before the next upload, to see if new bugs are
introduced.

(Note: yesterday's upload, 4.3.0-5, brings in several bug fixes that
Sam backported from GCC 4.4, as well as support for 64-bit PowerPC.
Debian is the only distribution that has these bug fixes and I didn't
want to deprive our users of them any longer. So, happy hacking :))

--
Ludovic Brenta.