Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Free AMD Core Math Library (BLAS/LAPACK) + Ada

1,688 views
Skip to first unread message

Ada novice

unread,
Jul 6, 2012, 2:38:02 PM7/6/12
to
Hi,
I came across the following:

http://developer.amd.com/libraries/acml/pages/default.aspx

This is a site for AMD computers for which free and full implementations of BLAS/LAPACK libraries are provided.

Have anyone tried the above and make it work with Ada?

Thanks,
YC

Charly

unread,
Jul 7, 2012, 9:37:35 AM7/7/12
to
> This is a site for AMD computers for which free and full implementations of BLAS/LAPACK libraries are provided.
>
> Have anyone tried the above and make it work with Ada?


Hello,

yes, you can use it (at least on Linux 64 bit), but you need ada bindings.
You can find bindings to both lapack and blas on the following addresses:

http://www.csee.umbc.edu/~squire/adaclass/lapack-ada/

http://topo.math.u-psud.fr/~sands/Programs/BLAS/ada_blas.tgz

For 64 bit OS you MUST use acml-5-1-0-gfortran-64bit.tgz, not
acml-5-1-0-gfortran-64bit-int64.tgz because the bindings use int32.

Of course it should be able to use the int64 version and make the necessary
modifications to the bindings, but I didn't test this.


Regards
Charly

Ada novice

unread,
Jul 7, 2012, 10:01:32 AM7/7/12
to
On Saturday, July 7, 2012 2:37:35 PM UTC+1, Charly wrote:
> yes, you can use it (at least on Linux 64 bit), but you need ada bindings.
> You can find bindings to both lapack and blas on the following addresses:
>
> http://www.csee.umbc.edu/~squire/adaclass/lapack-ada/
>
> http://topo.math.u-psud.fr/~sands/Programs/BLAS/ada_blas.tgz

Thanks. I have Windows 32 bit though on my AMD computer. But I see for Win 32 bits, version 5.1.0 is not yet available but two older versions namely:

acml4.4.0-ifort32.exe for Intel Fortran

and

acml4.4.0-pgi32.exe for PGI fortran

are offered. I do not have a Fortran compiler though.

Will just installing any of the two above libraries + bindings to LAPACK/BLAS (from the links that you mentioned) be sufficient?


Thanks
YC

Charly

unread,
Jul 8, 2012, 2:31:27 AM7/8/12
to
> Thanks. I have Windows 32 bit though on my AMD computer. But I see for Win 32 bits, version 5.1.0 is not yet available but two older versions namely:
>
> acml4.4.0-ifort32.exe for Intel Fortran
>
> and
>
> acml4.4.0-pgi32.exe for PGI fortran
>
> are offered. I do not have a Fortran compiler though.

Hello,

I can't say anything about Windows versions.

On my Linux box I achieved the follwing steps:

1). installed the acml library (for the gnu fortran compliler called gfortran)
with the attached install script. You don't need a fortran compiler, see step 2.).

2.) used GNAT GPL 2012 to do the following:
compiled the lapack binding (first link) and created a library called lapack-ada
compiled the blas binding (second link) and created a library called ada_blas
The bindings use the fortran-interface of ada, this is the reason why you must
use the fortran versions of the library in step 1.)

3.) took some of the demo-programs attached to the bindings, complied them and linked
them against the matching ada-library and the acml libray

That't it.

------
Charly
Message has been deleted

Ada novice

unread,
Jul 8, 2012, 8:22:35 AM7/8/12
to
Thanks. I installed the acml4.4.0-ifort32.exe for Intel Fortran package.

I tried the lapack and blas but I could not make them work. For example with blas, when I issue gnatmake *.adb -largs -L. I get

collect2: ld returned 1 exit status
gnatlink: error when calling C:\gnat\2011\bin\gcc.exe
gnatmake: *** link failed

I think that I have included everything I should in the Windows environment path. Ada_include_path and the Ada_project_path.

Any idea what could be wrong?

With blas, should I call: gnatmake *.adb -largs -L -lblas? Does that exist? And with lapack, should I add -llpack?


YC

Charly

unread,
Jul 9, 2012, 2:30:50 PM7/9/12
to
Am Sonntag, 8. Juli 2012 14:22:35 UTC+2 schrieb Ada novice:
> Thanks. I installed the acml4.4.0-ifort32.exe for Intel Fortran package.
>
> I tried the lapack and blas but I could not make them work. For example with blas, when I issue gnatmake *.adb -largs -L. I get
>
> collect2: ld returned 1 exit status
> gnatlink: error when calling C:\gnat\2011\bin\gcc.exe
> gnatmake: *** link failed
>
.....>
> YC
As I told you, I can't say meaningful things to windows problems.

On my linux box I give the following commands for the lapack example

gnatmake tcgeev.adb -largs -llapack-ada -lacml

and for the blas example

gnatmake example1.adb -largs -lada_blas -lacml

lapack-ada and ada_blas are the libraries that I created from the bindings,
acml is the AMD library.

All three libraries are in the standard search path for the linker.

I think at least the -lacml is missing in your command line.

-------
Charly



Ada novice

unread,
Jul 9, 2012, 5:15:26 PM7/9/12
to
On Monday, July 9, 2012 7:30:50 PM UTC+1, Charly wrote:
>
> and for the blas example
>
> gnatmake example1.adb -largs -lada_blas -lacml
>
>
> I think at least the -lacml is missing in your command line.

Thanks. This is what I am doing. If we just look at the blas binding, I've unzipped the contents in this directory:

E:\learnsof\ada\Ada_BLAS>

I have ACML installed in:

C:\AMD\acml4.4.0\

Before that I put the ACML folder in the windows environment path and also the current folder of the blas in the path. Just to be sure, I again do this when I am at the command prompt:

E:\learnsof\ada\Ada_BLAS>PATH="C:\AMD\acml4.4.0\ifort32\lib\libacml_dll.lib";"E:\learnsof\ada\Ada_BLAS";%PATH%

Then I run

E:\learnsof\ada\Ada_BLAS>gnatmake example1.adb -largs -L. -lacml
gnatbind -x example1.ali
gnatlink example1.ali -lblas -L. -lacml
c:/gnat/2011/bin/../libexec/gcc/i686-pc-mingw32/4.5.3/ld.exe: cannot find -lacml

collect2: ld returned 1 exit status
gnatlink: error when calling C:\GNAT\2011\bin\gcc.exe
gnatmake: *** link failed.

And it complains that it cannot find -lacml


I have 2 questions (not related to windows hopefully):

1. You issued the command:

gnatmake example1.adb -largs -lada_blas -lacml

About the -lada_blas, is ada_blas the FOLDER name for the blas binding? I use -l. after getting into the directory of my Ada_BLAS so that the current directory is specified with the dot "." .

2. I have been looking at the ACML manual but cannot find good information. Under Linux, do you have a method to test that your ACML is working without using it like above with gnatmake? For me -lacml was not recognised and I do not have a way to know if my ACML is installed correctly or not?

Thanks.
YC

Ada novice

unread,
Jul 9, 2012, 5:28:57 PM7/9/12
to
It seems that -lacml is not valid under Windows. In the ACML user guide, this command is only used with Unix.

YC

Nasser M. Abbasi

unread,
Jul 9, 2012, 5:36:56 PM7/9/12
to
On 7/9/2012 4:15 PM, Ada novice wrote:
>
>
> I have 2 questions (not related to windows hopefully):
>
> 1. You issued the command:
>
> gnatmake example1.adb -largs -lada_blas -lacml
>
> About the -lada_blas, is ada_blas the FOLDER name for the blas binding?

No. -L is used for the folder, and -l (small l) is used for
the name of the library. For example

-lgfortran means to look for libgfortran.so (for shared linking, the
default, unless you used -static, then it will look for .a).

The library must be libgfortran.so and not anything else, not even
libgfortran.so.1, if it is libgfortran.so.1 then the common fix is to
make a symbolic link.

Why not just install VBox on windows (it is free) and install
Linux on it (free) and just use Linux? So much easier. This
is what I do. My PC is running windows (because I need few apps
there), but I do all my programming on Linux on the VBox).

--Nasser

Ada novice

unread,
Jul 10, 2012, 1:03:43 AM7/10/12
to n...@12000.org
On Monday, July 9, 2012 10:36:56 PM UTC+1, Nasser M. Abbasi wrote:

> The library must be libgfortran.so and not anything else, not even
> libgfortran.so.1, if it is libgfortran.so.1 then the common fix is to
> make a symbolic link.

On the ACML site:

http://developer.amd.com/libraries/acml/downloads/pages/default.aspx

We do not have gfortran for Windows I think. What they offer are:

1. acml4.4.0-pgi32.exe built with PGI
2. acml4.4.0-ifort32.exe built with Intel Fortran.

I installed the latter one.


> Why not just install VBox on windows (it is free) and install
> Linux on it (free) and just use Linux? So much easier. This
> is what I do. My PC is running windows (because I need few apps
> there), but I do all my programming on Linux on the VBox).

I have AMD 32-bit and here I see that VBox does not exist for this type of architecture:

https://www.virtualbox.org/wiki/Downloads

Only AMD64 is offered for AMD.

YC

Simon Wright

unread,
Jul 10, 2012, 5:32:56 AM7/10/12
to
"Nasser M. Abbasi" <n...@12000.org> writes:

> The library must be libgfortran.so and not anything else, not even
> libgfortran.so.1, if it is libgfortran.so.1 then the common fix is to
> make a symbolic link.

I _think_ that on Windows gfortran.dll is also accepted.

Brian Drummond

unread,
Jul 10, 2012, 5:35:02 AM7/10/12
to
That's because AMD 32-bit is fully compatible with the "x86" download (or
should be!)

- Brian

Nasser M. Abbasi

unread,
Jul 10, 2012, 5:51:23 AM7/10/12
to
On 7/10/2012 4:35 AM, Brian Drummond wrote:
.
>>
>> I have AMD 32-bit and here I see that VBox does not exist for this type
>> of architecture:
>>
>> https://www.virtualbox.org/wiki/Downloads
>>
>> Only AMD64 is offered for AMD.
>
> That's because AMD 32-bit is fully compatible with the "x86" download (or
> should be!)
>
> - Brian

also many get confused by AMD64 thinking it is only for AMD.

AMD64 just says 64 bit. But it is for intel and for AMD. It is called
AMD64 (and not say INTEL64) because AMD was the first to make those
64 bit extensions instructions, then INTEL followed later. Hence
the name is stuck at AMD64.

x86 is 32 bit, and should work on intel 32 and amd 32 bits PC's.

I am on 64 bit intel PC, but I use VBox 32 bit guest OS's. i.e I
downloaded Linux 32 bit (not 64 bit). too long to explain but better
this way. I recommend Linux mint LXDE as it is light weight and
runs faster on VBox.

I tried them all (may be 30 linux distro's :) and found LXDE is best
for VBox as it consumes least resources. I really just need bash
shell and all the programming utilities/compilers, etc... do not
need all that extra fancy GUI that comes with GNOME3 and such. I
found GNOME3 too slow to run in VBox.

--Nasser

Ada novice

unread,
Jul 10, 2012, 8:29:18 AM7/10/12
to n...@12000.org
On Tuesday, July 10, 2012 10:51:23 AM UTC+1, Nasser M. Abbasi wrote:
>
> I tried them all (may be 30 linux distro&#39;s :) and found LXDE is best
> for VBox as it consumes least resources. I really just need bash
> shell and all the programming utilities/compilers, etc... do not
> need all that extra fancy GUI that comes with GNOME3 and such. I
> found GNOME3 too slow to run in VBox.
>

Thanks for all the info guys. I shall put VBox and install Linux Mint 13 Maya based on Mate which is a "Gnome 2" desktop.

http://www.linuxmint.com/download.php

YC

Ada novice

unread,
Jul 10, 2012, 4:02:50 PM7/10/12
to n...@12000.org
Now I have Linux mint 13 under VBox and it is working fine. The installation was horribly long though perhaps because of my slow machine. Before tackling ACML + Ada, I need to learn Linux as I have never used it before and tried some few Ada programs on their own. Two questions:

1. I see an x86-linux GNAT GPL at AdaCore libre that will be appropriate for my 32-bit system. Do I install this version or do I let "software manager" in my Linux mint to "find" the appropriate GNAT GPL?

2. I will install the acml-4-4-0-gfortran-32bit.tgz from ACML. Hope this works! Nevertheless I saw some lapack files already on my Linux. So should I just disregard these?

Thanks
YC

Nasser M. Abbasi

unread,
Jul 10, 2012, 5:48:15 PM7/10/12
to
On 7/10/2012 3:02 PM, Ada novice wrote:

> 1. I see an x86-linux GNAT GPL at AdaCore libre that will be
>appropriate for my 32-bit system. Do I install this version or
>do I let "software manager" in my Linux mint to "find" the appropriate GNAT GPL?
>

GNAT GPL 2012 is only available from Libre, that is what I used. Download
that from Libre website (select linux) and install it. Do not
use the package manager version of GNAT, that will be older one.

> 2. I will install the acml-4-4-0-gfortran-32bit.tgz from ACML.
>Hope this works! Nevertheless I saw some lapack files already on my Linux.
>So should I just disregard these?

Do not remove anything manually. Install Lapack and Blas from
the cynaptic package manager. Search for liblapack3gf and
libblas3gf and select them and install them. That is all.

Then define in your .bashrc file the LD_LIBRARY_PATH.
See my earlier notes on installation on this for more
info.

I did not install acml myself.

--Nasser


Simon Wright

unread,
Jul 11, 2012, 3:49:03 AM7/11/12
to
Ada novice <shai...@gmx.com> writes:

> 2. I will install the acml-4-4-0-gfortran-32bit.tgz from ACML. Hope
> this works! Nevertheless I saw some lapack files already on my
> Linux. So should I just disregard these?

The reason you were pursuing ACML was that you might have been able to
get it to work with Ada *on Windows*. On Linux, you can use the
already-packaged LAPACK/BLAS libraries (as Nasser has said, you'll need
to load them using the package manager; I'd expect loading LAPACK would
automagically load BLAS).

Ken Thomas

unread,
Jul 11, 2012, 5:47:47 AM7/11/12
to
On Wednesday, July 11, 2012 8:49:03 AM UTC+1, Simon Wright wrote:
> Ada novice &lt;shai...@gmx.com&gt; writes:
>
> &gt; 2. I will install the acml-4-4-0-gfortran-32bit.tgz from ACML. Hope
> &gt; this works! Nevertheless I saw some lapack files already on my
> &gt; Linux. So should I just disregard these?
>
> The reason you were pursuing ACML was that you might have been able to
> get it to work with Ada *on Windows*. On Linux, you can use the
> already-packaged LAPACK/BLAS libraries (as Nasser has said, you&#39;ll need
> to load them using the package manager; I&#39;d expect loading LAPACK would
> automagically load BLAS).

Perhaps we should remember the motivation of the BLAS/LAPACK. A standard specification that is implemented by hardware companies such as Intel, AMD using all the wizardry to obtain high performance. A related question is given the Ada .Numerics package Generic_Real_Arrays how do we modify the build to link in the high performance tools?
Message has been deleted

Georg Bauhaus

unread,
Jul 11, 2012, 11:48:36 AM7/11/12
to
On 11.07.12 17:32, Ada novice wrote:
> shailesh@shailesh_virtualbox -$ cd /Ada_Blas
>
> I get: "bash: cd: Ada_Blas: No such file or directory"

I'd try studying paths in a hierarchical filesystem and how
to name thins in it, both absolute (full) paths and relative
paths (such as Ada_blas).

http://people.ischool.berkeley.edu/~kevin/unix-tutorial/section3.html

Ada novice

unread,
Jul 11, 2012, 12:54:34 PM7/11/12
to
On Wednesday, July 11, 2012 4:48:36 PM UTC+1, Georg Bauhaus wrote:

> http://people.ischool.berkeley.edu/~kevin/unix-tutorial/section3.html

Thanks for the link. That helped and I fixed that part.

In step 5 from Nasser:

http://12000.org/my_notes/ada/index.htm

On issuing gnatmake *.adb, I get:

gcc-4.6 -c ada_blas-complex.adb
gcc-4.6 -c ada_blas.ads
gcc-4.6 -c ada_blas-real.adb
gcc-4.6 -c example1.adb
gcc-4.6 -c example_support.ads
gnatbind -x example1.ali
gnatlink exmaple1.ali

./exmaple_support_o: In function `example_support_real__blas_amax`
example_suport.ads(.text+0xeb): undefined reference to `isamax_`

lots of "similar" lines follow

collect2: ld returned 1 exit status
gnatlink: error when calling (usr/bin gcc-4.6
gnatmake: *** link failed

Any clue what is going wrong?

Thanks.

YC






Simon Wright

unread,
Jul 11, 2012, 1:37:19 PM7/11/12
to
You aren't telling the linker that your software needs libblas.

Try

gnatmake example1.adb -largs -lblas

Nasser M. Abbasi

unread,
Jul 11, 2012, 2:17:15 PM7/11/12
to
On 7/11/2012 11:54 AM, Ada novice wrote:
> On Wednesday, July 11, 2012 4:48:36 PM UTC+1, Georg Bauhaus wrote:

>
> In step 5 from Nasser:
>
> http://12000.org/my_notes/ada/index.htm
>
> On issuing gnatmake *.adb, I get:
>
> gcc-4.6 -c ada_blas-complex.adb
> gcc-4.6 -c ada_blas.ads
> gcc-4.6 -c ada_blas-real.adb
> gcc-4.6 -c example1.adb
> gcc-4.6 -c example_support.ads
> gnatbind -x example1.ali
> gnatlink exmaple1.ali
>
> ./exmaple_support_o: In function `example_support_real__blas_amax`
> example_suport.ads(.text+0xeb): undefined reference to `isamax_`
>

This is a blas link.

once you have done step (2) in the cheat sheet above, you
need to refresh your .bashrc to make sure those environment
variables are exported. i.e. type

>source $HOME/.bashrc

(first time you login or start a new terminal, this is done
automatically as part of making a new shell, but it seems
you did not do login after adding those env. variables to your
.bashrc).

Now, type

>echo $LD_LIBRARY_PATH to make sure they are defined.

Now gnatmake in step(5) should work. (assuming you did step
(1) which is installation of the blas and lapack and that
LD_LIBRARY_PATH is correct pointing to the those libraries.

But step(5) is missing one thing, I'll fix the cheat sheet
now. Please try this command instead to build the BLAS files

-----------------------------
>ls /usr/lib/atlas-base/atlas/
libblas.so.3gf libblas.so.3gf.0 liblapack.so.3gf liblapack.so.3gf.0

>gnatmake *.adb -largs -lblas
gnatbind -x example1.ali
gnatlink example1.ali -lblas
gnatbind -x print_precisions.ali
gnatlink print_precisions.ali -lblas

>./example1
Dot product is: 0.00000E+00
>
-----------------------------

Notice you need to add -largs -lblas to gnatmake command to tell
it the library to link to (the blas library).

the LD_LIBRARY_PATH is just for convenience to that I do
have to type the path each time I call gnatmake.

You do not really needed, you can pass gnatmake all the arguments
each time like this:

-------------------------------
>export LD_LIBRARY_PATH= #clear it
>echo $LD_LIBRARY_PATH

>gnatmake *.adb -largs -lblas -L/usr/lib/atlas-base/atlas
gnatmake: "example1" up to date.
gnatbind -x print_precisions.ali
gnatlink print_precisions.ali -lblas -L/usr/lib/atlas-base/atlas
>
---------------------------------------

As for you other question on empty .bashrc, that is fine. I also
had no .bashrc file when I installed mint. You can
just create one in text editor. Also there are many templates
of .bashrc on the net you can copy and edit for your use. But for
now, just keep it simple and make one and use it.

-Nasser

Ada novice

unread,
Jul 11, 2012, 3:14:06 PM7/11/12
to n...@12000.org
On Wednesday, July 11, 2012 7:17:15 PM UTC+1, Nasser M. Abbasi wrote:
> But step(5) is missing one thing, I&#39;ll fix the cheat sheet
> now. Please try this command instead to build the BLAS files
>

Thanks Nasser and Simon for your kind help. I can report that the Blas is now working after following your latest instructions and that I get the same output as in point 6 here:

http://12000.org/my_notes/ada/index.htm

I will move on to the Lapack binding (ATLAS) now.


> ---------------------------------------
>
> As for you other question on empty .bashrc, that is fine. I also
> had no .bashrc file when I installed mint. You can
> just create one in text editor. Also there are many templates
> of .bashrc on the net you can copy and edit for your use. But for
> now, just keep it simple and make one and use it.

I am still a few hours in Linux and I still have to know what a .bashrc is all about. Thanks for the information.

YC

Simon Wright

unread,
Jul 11, 2012, 3:30:45 PM7/11/12
to
Ken Thomas <k...@ecs.soton.ac.uk> writes:

> Perhaps we should remember the motivation of the BLAS/LAPACK. A
> standard specification that is implemented by hardware companies such
> as Intel, AMD using all the wizardry to obtain high performance. A
> related question is given the Ada .Numerics package
> Generic_Real_Arrays how do we modify the build to link in the high
> performance tools?

Well, with GNAT GPL 2012/GCC 4.7 you can't, because Generic_Real_Arrays
has been rewritten in pure Ada (using Jacobi, which I gather is not
known to be fast) in order not to use BLAS because of a feeling that
some BLAS's might use an unacceptable numeric approximation. Personally
I think this was daft.
Message has been deleted

Ada novice

unread,
Jul 11, 2012, 3:52:20 PM7/11/12
to
Nasser, in your step 10 from:

http://12000.org/my_notes/ada/index.htm

for the lapack binding, you type:

cd lapada/test/lapack
make all

and in the generated log file, I could find entries such as:

gcc -c -I./ -I../../../ada -I- /media/nabbasi/data/ada_related/lapack-ada_95_binding_downloaded_june_2012/lapada/ada/ladrv.ads

I too have such a long log file but I do not have the entries with "downloaded_june_2012".

When I "make all", my computer my offline. Do I need to connect to the internet at this stage?


Thanks.
YC

Simon Wright

unread,
Jul 11, 2012, 5:39:43 PM7/11/12
to
Simon Wright <si...@pushface.org> writes:

> Well, with GNAT GPL 2012/GCC 4.7 you can't, because Generic_Real_Arrays
> has been rewritten in pure Ada (using Jacobi, which I gather is not
> known to be fast) in order not to use BLAS because of a feeling that
> some BLAS's might use an unacceptable numeric approximation. Personally
> I think this was daft.

Eigensystem, on a matrix of rank 250, took 0.07s with GCC 4.6 and 4.7s
with GCC 4.7.

Nasser M. Abbasi

unread,
Jul 11, 2012, 5:50:01 PM7/11/12
to
On 7/11/2012 2:52 PM, Ada novice wrote:
> Nasser, in your step 10 from:
>
> http://12000.org/my_notes/ada/index.htm
>
> for the lapack binding, you type:
>
> cd lapada/test/lapack
> make all
>
> and in the generated log file, I could find entries such as:
>
> gcc -c -I./ -I../../../ada -I- /media/nabbasi/data/ada_related/lapack-ada_95_binding_downloaded_june_2012/lapada/ada/ladrv.ads
>
> I too have such a long log file but I do not have the entries with "downloaded_june_2012".

This is just a log file. I happend to be on using that shared folder
at the time.

Do not worry about the path such as those. the path on my PC
where I put the source files will be different than
your PC. the 'cd lapada/test/lapack' was just an example ! not
to be meant to be taken literally. You can put the sources
any where you want. I put them on my /media since that
is where I have my shared folder mounted.

I put the log file there just to show what one would expect as
output.

hth

--Nasser

Ada novice

unread,
Jul 12, 2012, 2:34:16 AM7/12/12
to n...@12000.org
On Wednesday, July 11, 2012 10:50:01 PM UTC+1, Nasser M. Abbasi wrote:
>
> Do not worry about the path such as those. the path on my PC
> where I put the source files will be different than
> your PC. the &#39;cd lapada/test/lapack&#39; was just an example ! not
> to be meant to be taken literally.

Sure. Right now I am just making the bindings work and I am following your cheat sheet so as to be quick. Afterwards, I can put the files in some other folders as desired.

In your cheat sheet in step 11, you are locating gfortran. When I typed:

>locate libgfortran

I got nothing. So I installed gfortran via the package manager and still after that

>locate libgfortran

does not give me anything. But I can find the files as in your cheat sheet via browsing in my usr folder:

/usr/lib/i386-linux-gnu/libgfortran.so.3
/usr/lib/i386-linux-gnu/libgfortran.so.3.0.0

The locate command seems to work if I say "locate gps" but in case of "locate libgfortran", it does not return me anything though I the two files as written above.

YC

Simon Wright

unread,
Jul 12, 2012, 4:38:19 AM7/12/12
to
Ada novice <shai...@gmx.com> writes:

> The locate command seems to work if I say "locate gps" but in case of
> "locate libgfortran", it does not return me anything though I the two
> files as written above.

locate works on an index of the filesystem, which needs to be rebuilt
when you add files. Of course you only really care about 'system' files
like libgfortran.

The index (database) is updated by updatedb(8): from
http://linux.die.net/man/8/updatedb,

updatedb creates or updates a database used by locate(1). If the
database already exists, its data is reused to avoid rereading
directories that have not changed.

updatedb is usually run daily by cron(8) to update the default
database.

You should be able to find the equivalent on your system by saying 'man
updatedb'.

The 'daily' part probably relies on the Linux system being up all the
time, so (if the database isn't rebuilt when the system is booted) you
may need to do it by hand.

Ada novice

unread,
Jul 13, 2012, 3:38:31 PM7/13/12
to
On Thursday, July 12, 2012 9:38:19 AM UTC+1, Simon Wright wrote:
> Ada novice &lt;shai...@gmx.com&gt; writes:

> You should be able to find the equivalent on your system by saying &#39;man
> updatedb&#39;.
>

Thanks. I changed to a Debian linux and I need to gets some hands on experience with Linux.

YC

Ada novice

unread,
Jul 14, 2012, 10:25:44 AM7/14/12
to
I have redone the steps for the BLAS on my new Linux mint debian but could not make it work. On compiling I get the message:

/usr/bin/ld: cannot find -lblas

causing gnatlink to fail.

I have done all previous steps well, checking the directories and making sure that BLAS is there and that the right path is in the .bashrc file. The BLAS files are in /usr/lib/atlas-base/atlas as expected. Lapack has also been installed as well.

What may be causing this error message?

Thanks.
YC

John B. Matthews

unread,
Jul 14, 2012, 10:20:11 PM7/14/12
to
In article <9cc53435-3c7f-4443...@googlegroups.com>,
Adding -v or -v -v to the -largs will produce more verbose output from
the linker. I usually find an extra space or an incorrectly escaped
character.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Ada novice

unread,
Jul 15, 2012, 3:41:52 AM7/15/12
to
On Sunday, July 15, 2012 3:20:11 AM UTC+1, John B. Matthews wrote:
> In article &lt;9cc53435-3c7f-4443...@googlegroups.com&gt;,
> Adding -v or -v -v to the -largs will produce more verbose output from
> the linker. I usually find an extra space or an incorrectly escaped
> character.

Thanks. I cannot locate the article 9cc53435-3c7f-4443...@googlegroups.com. This resembles like an email address.


Yes -v or -v -v works. I have put it as -largsv or -largsvv. Or should it be as -largs -v and -largs -v -v ?


Anyway, -largsv or -largsvv gives me the output that I had in one similar post here earlier:

./exmaple_support_o: In function `example_support_real__blas_amax`
example_suport.ads(.text+0xeb): undefined reference to `isamax_`

and several similar lines follows

collect2: ld returned 1 exit status
gnatlink: error when calling (usr/bin gcc-4.4
gnatmake: *** link failed

I've checked >ls /usr/lib/atlas-base/atlas/
libblas.so.3gf libblas.so.3gf.0 liblapack.so.3gf liblapack.so.3gf.0

and the blas files are there physically.

I've typed echo $LD_LIBRARY_PATH, I get:
/usr/lib/i386-linux-gnu/:/usr/lib/atlas-base/:/usr/lib/atlas-base/atlas

which is correct

And I have tried with gnatmake *.adb -largs -lblas -L/usr/lib/atlas-base/atlas
which gives me the same output as above with same errors.


The only differences between making it work on my last linux distribution and the present one is that now I am using gnat 4.4 instead of gnat 4.6 and that I have put the ADA_Blas folder a bit deeper rather in Home itself but this is irrelevant.


Thanks.
YC

Simon Wright

unread,
Jul 15, 2012, 7:25:49 AM7/15/12
to
-largs -v gives the -v (verbose) switch to gnatlink. If you want to give
-v to the system linker, ld, you would say

-largs -Wl,-v

(*exactly* as typed!)

LD_LIBRARY_PATH is used at run time to tell the program loader where to
find extra shared libraries; what you need is to tell the linker where
to find extra shared libraries. Use LIBRARY_PATH as well.

See
http://stackoverflow.com/questions/4250624/ld-library-path-vs-library-path,
for example.

Ada novice

unread,
Jul 15, 2012, 9:22:10 AM7/15/12
to
On Sunday, July 15, 2012 12:25:49 PM UTC+1, Simon Wright wrote:
> -largs -v gives the -v (verbose) switch to gnatlink. If you want to give
> -v to the system linker, ld, you would say
>
> -largs -Wl,-v
>
> (*exactly* as typed!)

OK. With SPACE after "WI," I get with gnatmake *.adb -largs -WI, -v -lblas:

gnatbind -x example1.ali
gnatlink example1.ali -WI, -v -lblas

GNATLINK 4.4.6
Copyright (C) 1995-2008, Free Software Foundation, Inc.
gcc-4 -c -gnatA -gnatWb -gnatiw -gnatws /home/yc/work/ada/testblas/Ada_BLAS/b~example1.adb
/usr/bin/gcc-4.4 b~example1.o ./ada_blas.o ./ada_blas-real.o ./example_support.o ./example1.o -WI, -lblas -o example1 -L./ -L/usr/lib/gcc/i486-linux-gnu/4.4/adalib/ -lgnat-4.4 -shared-libgcc
/usr/bin/ld: cannot find -lblas
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/bin/gcc-4.4
gnatmake: *** link failed.

> LD_LIBRARY_PATH is used at run time to tell the program loader where to
> find extra shared libraries; what you need is to tell the linker where
> to find extra shared libraries. Use LIBRARY_PATH as well.

my $HOME.bashrc file had the following lines:

export LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu/:/usr/lib/atlas-base/:/usr/lib/atlas-base/atlas/
export LIBRARY_PATH=/usr/lib/i386-linux-gnu/

and I modified LIBRARY_PATH to have the same contents as LD_LIBRARY_PATH i.e.
/usr/lib/i386-linux-gnu/:/usr/lib/atlas-base/:/usr/lib/atlas-base/atlas/

but I get the same error messages.

YC


Georg Bauhaus

unread,
Jul 15, 2012, 10:59:23 AM7/15/12
to
On 15.07.12 15:22, Ada novice wrote:
>> > -largs -Wl,-v
>> >
>> >(*exactly* as typed!)
> OK. With SPACE after "WI," I get with gnatmake *.adb -largs -WI, -v -lblas:

Did to put a space there on purpose? Also, that's an 'l', ell,
after 'W'. In the GCC man page,

-Wl,option

is listed among Linker Options. {option} needs to be separated
from the 'l', but also needs to be connected to 'Wl', not counted
among other options for gcc, not the linker. So some separator is needed,
which is the reason for the ',', I think.

Georg Bauhaus

unread,
Jul 15, 2012, 11:06:02 AM7/15/12
to
This was unclear. Let me try again.

gcc has options such as -Wall or -Wextra, where 'W'
is followed by characters, syntactically.
'l' is a character. Thus, -Wl looks like a gcc switch.

For any letter 'X', -X is a gcc switch, syntactically.
For it to be a linker option, it needs to be different.
Or placed in a location where switches are considered
not to be for gcc. (For illustration, the latter technique
is used by the GNAT front end. You'd use -largs or -bargs
to indicate locations for gnatlink switches and gnatbind
switches.)

So, -Wl,-v (without space) keeps gcc from considering -v
a switch for gcc.

Simon Wright

unread,
Jul 15, 2012, 11:09:05 AM7/15/12
to
Ada novice <shai...@gmx.com> writes:

> On Sunday, July 15, 2012 12:25:49 PM UTC+1, Simon Wright wrote:
>> -largs -v gives the -v (verbose) switch to gnatlink. If you want to give
>> -v to the system linker, ld, you would say
>>
>> -largs -Wl,-v
>>
>> (*exactly* as typed!)
>
> OK. With SPACE after "WI," I get with gnatmake *.adb -largs -WI, -v -lblas:

You must have some unsatisfactory-for-programmers font that makes it
hard to distinguish lowercase-ell from capital-eye (sorry, I realise
English may not be your native language):

dash capital-doubleyou lowercase-ell comma dash lowercase-vee

But, in any case, it seems that there is no libblas.a or libblas.so on
your LIBRARY_PATH.

I'm a bit lost here, on Debian 6 the situation with libblas and atlas is
confused or at any rate confusing; and the /etc/alternatives scheme is
weird. I find it hard to believe that uninstalling the plain libblas
means I have to uninstall chunks of Gnome!

But I have a working libblas and liblapack setup without messing with
Atlas. And I see that the Atlas package writeup says it isn't really
optimised anyway, being as it's highly architecture-dependent. So why
bother with it?

Message has been deleted

Ada novice

unread,
Jul 15, 2012, 12:05:49 PM7/15/12
to
On Sunday, July 15, 2012 4:09:05 PM UTC+1, Simon Wright wrote:
>
> You must have some unsatisfactory-for-programmers font that makes it
> hard to distinguish lowercase-ell from capital-eye

Thanks for your inputs George and Simon. Yes I did type I as in I-Robot instead of ell. Ok, this is what I have:

apt-cache policy liblapack3gf gives
liblapack3gf:
Installed: 3.3.1-1
Candidate: 3.3.1-1

apt-cache policy libblas3gf gives
libblas3gf:
Installed: 1.2.20110419-2
Candidate: 1.2.20110419-2

and now I locate libblas:
locate libblas
/etc/alternatives/libblas.so.3gf
/usr/lib/libblas
/usr/lib/libblas.so.3gf
/usr/lib/atlas-base/atlas/libblas.so.3gf
/usr/lib/atlas-base/atlas/libblas.so.3gf.0
/usr/lib/libblas/libblas.so.3gf
/usr/lib/libblas/libblas.so.3gf.0
/usr/share/doc/libblas3gf
/usr/share/doc/libblas3gf/README.Debian.gz
/usr/share/doc/libblas3gf/blas.patch.gz
/usr/share/doc/libblas3gf/changelog.Debian.gz
/usr/share/doc/libblas3gf/copyright
/usr/share/doc/libblas3gf/test_results.gz
/var/lib/dpkg/alternatives/libblas.so.3gf
/var/lib/dpkg/info/libblas3gf.list
/var/lib/dpkg/info/libblas3gf.md5sums
/var/lib/dpkg/info/libblas3gf.postinst
/var/lib/dpkg/info/libblas3gf.postrm
/var/lib/dpkg/info/libblas3gf.prerm
/var/lib/dpkg/info/libblas3gf.shlibs

Simon, I do not have libblas.a and libblas.so as you wrote in your last post that I should.

Now I do not make reference to ATLAS. So I modified my .bashrc as follows:
cat $HOME/.bashrc
export LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu/:/usr/lib/libblas/
export LIBRARY_PATH=/usr/lib/i386-linux-gnu/:/usr/lib/libblas/

and I see the folder /usr/lib/libblas has the following files:
libblas.so.3gf and libblas.so.3gf.0

and echo $LIBRARY_PATH gives
/usr/lib/i386-linux-gnu/:/usr/lib/libblas/

Then on compiling:

gnatmake *.adb -largs -Wl,-v -lblas
gnatbind -x example1.ali
gnatlink example1.ali -Wl,-v -lblas
collect2 version 4.4.6 (i386 Linux/ELF)
/usr/bin/ld --build-id --no-add-needed --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o example1 /usr/lib/gcc/i486-linux-gnu/4.4.6/../../../i386-linux-gnu/crt1.o /usr/lib/gcc/i486-linux-gnu/4.4.6/../../../i386-linux-gnu/crti.o /usr/lib/gcc/i486-linux-gnu/4.4.6/crtbegin.o -L./ -L/usr/lib/gcc/i486-linux-gnu/4.4/adalib/ -L/usr/lib/gcc/i486-linux-gnu/4.4.6 -L/usr/lib/gcc/i486-linux-gnu/4.4.6 -L/usr/lib/gcc/i486-linux-gnu/4.4.6/../../../i386-linux-gnu -L/usr/lib/gcc/i486-linux-gnu/4.4.6/../../../../lib -L/lib/i386-linux-gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/libblas -L/usr/lib/gcc/i486-linux-gnu/4.4.6/../../.. b~example1.o ./ada_blas.o ./ada_blas-real.o ./example_support.o ./example1.o -v -lblas -lgnat-4.4 -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i486-linux-gnu/4.4.6/crtend.o /usr/lib/gcc/i486-linux-gnu/4.4.6/../../../i386-linux-gnu/crtn.o
GNU ld (GNU Binutils for Debian) 2.22
/usr/bin/ld: cannot find -lblas
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/bin/gcc-4.4
gnatmake: *** link failed.

So what should I do next?

Should I uninstall ATLAS completely? Is the following a neat uninstall? :

apt-get autoremove libatlas3gf-base

Thanks.
YC

Simon Wright

unread,
Jul 15, 2012, 12:47:07 PM7/15/12
to
Ada novice <shai...@gmx.com> writes:

> locate libblas
> /etc/alternatives/libblas.so.3gf
> /usr/lib/libblas
> /usr/lib/libblas.so.3gf
> /usr/lib/atlas-base/atlas/libblas.so.3gf
> /usr/lib/atlas-base/atlas/libblas.so.3gf.0
> /usr/lib/libblas/libblas.so.3gf
> /usr/lib/libblas/libblas.so.3gf.0

> Simon, I do not have libblas.a and libblas.so as you wrote in your
> last post that I should.

I have no idea how they got into my system! but that's what's missing.

When you say '-lblas' that tells the linker to look for libblas.so (or
maybe libblas.a, I'm not sure of the rules). It looks in various places;
the default will certainly include /usr/lib/.

I think we should create libblas.so there. You will need to do this as
root; be very careful! (if anyone else is listening and knows a better
way, please say so ...)

This sequence will create a symbolic link or symlink in /usr/lib/ so
that when the linker looks for libblas.so it finds it, and when it opens
it the system chases the symlink(s) until it finds a real file, which is
what gets opened. 'ln -s' creates a symlink; 'man ln' for more info.

Again, be careful. You may want to practice first, using your normal
account in some scratch directory.

$ cd /usr/lib
$ su
Password: enter root's password here
# ln -s libblas.so.3gf libblas.so
# exit
$

(I'm assuming that /usr/lib/libblas.so.3gf is at least a symlink to a
real library!)

It looks to me as though it's at least possible that the files in
/usr/lib/atlas-base/atlas/ and /usr/lib/libblas/ are in fact the
same.

> Now I do not make reference to ATLAS. So I modified my .bashrc as follows:
> cat $HOME/.bashrc
> export LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu/:/usr/lib/libblas/
> export LIBRARY_PATH=/usr/lib/i386-linux-gnu/:/usr/lib/libblas/
>
> and I see the folder /usr/lib/libblas has the following files:
> libblas.so.3gf and libblas.so.3gf.0
>
> and echo $LIBRARY_PATH gives
> /usr/lib/i386-linux-gnu/:/usr/lib/libblas/

If we manage to create /usr/lib/libblas.so you shouldn't need any of
this. But it won't harm to leave it for the moment.

> So what should I do next?
>
> Should I uninstall ATLAS completely? Is the following a neat uninstall? :
>
> apt-get autoremove libatlas3gf-base

I think I may have misled you here; I'd leave it alone for now.

Ada novice

unread,
Jul 15, 2012, 1:03:19 PM7/15/12
to
On Sunday, July 15, 2012 5:47:07 PM UTC+1, Simon Wright wrote:

> $ cd /usr/lib
> $ su
> Password: enter root&#39;s password here
> # ln -s libblas.so.3gf libblas.so
> # exit
> $


Should not it be the folder $ cd /usr/lib/libblas since it is the latter that contains libblas.so.3gf ?


> I think I may have misled you here; I&#39;d leave it alone for now.
I'm just re-installing the linux on the VBox. The BLAS worked the last time without I installed ATLAS. So I will just search for liblapack via the package manager, see if it is also getting libblas at the same time and then test again.

If it is still not working, then I will try your method.

Thanks.
YC

Ludovic Brenta

unread,
Jul 15, 2012, 1:42:10 PM7/15/12
to
Simon Wright writes on comp.lang.ada
> Ada novice <shai...@gmx.com> writes:
>
>> locate libblas
>> /etc/alternatives/libblas.so.3gf
>> /usr/lib/libblas
>> /usr/lib/libblas.so.3gf
>> /usr/lib/atlas-base/atlas/libblas.so.3gf
>> /usr/lib/atlas-base/atlas/libblas.so.3gf.0
>> /usr/lib/libblas/libblas.so.3gf
>> /usr/lib/libblas/libblas.so.3gf.0
>
>> Simon, I do not have libblas.a and libblas.so as you wrote in your
>> last post that I should.
>
> I have no idea how they got into my system! but that's what's missing.

If you don't know what package provides a file:

dpkg -S /full/path/to/the/file

> When you say '-lblas' that tells the linker to look for libblas.so (or
> maybe libblas.a, I'm not sure of the rules). It looks in various places;
> the default will certainly include /usr/lib/.

The compiler looks only for libblas.so. If you want to link statically
against libblas.a, you don't say -lblas but /usr/lib/libblas.a instead.

> I think we should create libblas.so there. You will need to do this as
> root; be very careful! (if anyone else is listening and knows a better
> way, please say so ...)

Install the -dev package corresponding to the runtime library package
containing libblas.so.3gf, per Debian Policy section 8.4[1] and as
discussed at excruciating length in the Debian Policy for Ada[2],
section 3, "Ada and shared libraries".

[1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev
[2] http://people.debian.org/~lbrenta/debian-ada-policy.html#Ada-and-shared-libraries

libblas is a little special because there are two different libblases.
On the one hand:

* libblas3 provides /usr/lib/libblas/libblas.so.3gf -> libblas.so.3gf.0
* libblas-dev provides /usr/lib/libblas/libblas.so -> libblas.so.3gf

On the other hand:

* libatlas3-base provides /usr/lib/libblas/libblas.so.3 -> libblas.so.3.0
* libatlas-base-dev provides /usr/lib/atlas-base/atlas/libblas.so -> libblas.so.3

[3] http://packages.debian.org/search?searchon=contents&keywords=libblas.so&mode=exactfilename&suite=testing&arch=any

The reason why neither package provides /usr/lib/liblas.so* is so you
can install them both simultaneously and select which one provides the
canonical /usr/lib/libblas.so.* using the alternatives system, which
exists for just this purpose.

Note that the two libraries have different sonames (libblas.so.3gf as
opposed to libblas.so.3) and are therefore probably incompatible. This
means that after you've selected one of the two libraries, using the
alternatives system, you will create a binary executable program that
depends on that library and will not work with the other.

> This sequence will create a symbolic link or symlink in /usr/lib/ so
> that when the linker looks for libblas.so it finds it, and when it
> opens it the system chases the symlink(s) until it finds a real file,
> which is what gets opened. 'ln -s' creates a symlink; 'man ln' for
> more info.

It is bad advice to modify anything under / or /usr by hand; these
directories are under sole control of the Debian packaging system (or
whichever distribution you use). If you're going to mess with files
manually, do that under /usr/local, which exists for this very purpose.
As a general rule, do not interfere with dpkg!

> Again, be careful. You may want to practice first, using your normal
> account in some scratch directory.
>
> $ cd /usr/lib
> $ su
> Password: enter root's password here
> # ln -s libblas.so.3gf libblas.so
> # exit
> $

As I said: don't do that. Ever. Let the alternatives system do that
for you in a controlled way. If you don't know about the alternatives
system, read the update-alternatives(8) man page. You should use
update-alternatives manually only in very rare cases; most often,
installing one of libatlas-base-dev or libblas-dev should update the
alternatives automatically for you, possibly with an interactive menu
asking you which one to use; read carefully what dpkg says when it
installs the packages.

Hope this helps

--
Ludovic Brenta.

Simon Wright

unread,
Jul 15, 2012, 2:41:29 PM7/15/12
to
Ludovic,

Thanks for that. We really needed advice from someone who knows.

By way of experiment, I removed liblapack-dev which left
/usr/lib/liblapack.{a,so} pointing to the now deleted /etc/alternatives/
files. So I suppose the /usr/lib files get created when
update-alternatives is run after a new install of libfoo-dev?

Ludovic Brenta

unread,
Jul 15, 2012, 4:06:32 PM7/15/12
to
Simon Wright writes on comp.lang.ada:
Correct but only if libfoo-dev participates in the alternatives system.
Only few libraries do; BLAS is one but I don't know whether LAPACK also
has alternatives. I'll let you know how I find that out without
installing anything on my system:

- go to http://www.debian.org/distrib/packages#search_contents
- type liblapack.so in the Keyword field
- tick "packages that contain files named like this"
- choose the distribution: in your case , "Stable" (i.e. Debian 6
"Squeeze").

Results:

/usr/lib/atlas-base/atlas/liblapack.so libatlas-base-dev
/usr/lib/lapack/liblapack.so liblapack-dev

So there is the answer: two -dev packages provide liblapack.so (the
development-time symlink to the run-time shared library) in different
subdirectories of /usr/lib. Therefore these two packages can be
installed simultaneously. Also, no package provides
/usr/lib/liblapack.so. Therefore the two packages above probably
participate in the alternatives system. If the two packages are done
correctly:

- installing the first -dev package will initialize the alternatives
system and create /usr/lib/liblapack.so to point to
/usr/lib/$package/liblapack.so.

- installing the second -dev package should ask you whether or not to
change the default to be the new liblapack.so or tell you that it
updated the alternative without asking (in the output of dpkg).

- uninstalling one of the -dev packages should automatically change the
alternative to point to the remaining liblapack.so; therefore you
should never be left with a dangling symlink.

If any of these things fail to happen (and you are sure you did not
tamper with symlinks by hand), please file a bug against the -dev
package that you installed or removed last.

--
Ludovic Brenta.

Simon Wright

unread,
Jul 15, 2012, 4:41:56 PM7/15/12
to
Ludovic Brenta <lud...@ludovic-brenta.org> writes:

> Simon Wright writes on comp.lang.ada:
>> Thanks for that. We really needed advice from someone who knows.
>>
>> By way of experiment, I removed liblapack-dev which left
>> /usr/lib/liblapack.{a,so} pointing to the now deleted /etc/alternatives/
>> files. So I suppose the /usr/lib files get created when
>> update-alternatives is run after a new install of libfoo-dev?
>
> Correct but only if libfoo-dev participates in the alternatives system.

> If the two packages are done
> correctly:
>
> - installing the first -dev package will initialize the alternatives
> system and create /usr/lib/liblapack.so to point to
> /usr/lib/$package/liblapack.so.
>
> - installing the second -dev package should ask you whether or not to
> change the default to be the new liblapack.so or tell you that it
> updated the alternative without asking (in the output of dpkg).
>
> - uninstalling one of the -dev packages should automatically change the
> alternative to point to the remaining liblapack.so; therefore you
> should never be left with a dangling symlink.
>
> If any of these things fail to happen (and you are sure you did not
> tamper with symlinks by hand), please file a bug against the -dev
> package that you installed or removed last.

I think what I did was to uninstall the last -dev package.

Ada novice

unread,
Jul 15, 2012, 5:24:06 PM7/15/12
to
Thank you for the interesting discussions. I finally got BLAS to work.

On my fresh linux in the vbox, I installed gnat, liblapack-dev and libblas-dev.

apt-cache policy libblas-dev
libblas-dev:
Installed: 1.2.20110419-2
Candidate: 1.2.20110419-2
Version table:
*** 1.2.20110419-2 0
500 http://debian.linuxmint.com/latest/ testing/main i386 Packages
100 /var/lib/dpkg/status

apt-cache policy liblapack-dev
liblapack-dev:
Installed: 3.3.1-1
Candidate: 3.3.1-1
Version table:
*** 3.3.1-1 0
500 http://debian.linuxmint.com/latest/ testing/main i386 Packages
100 /var/lib/dpkg/status

And I compiled using gnatmake *.adb -largs -lblas. Et voila!

gcc-4.4 -c ada_blas-complex.adb
gcc-4.4 -c ada_blas.ads
gcc-4.4 -c ada_blas-real.adb
gcc-4.4 -c example1.adb
gcc-4.4 -c example_support.ads
gnatbind -x example1.ali
gnatlink example1.ali -lblas
gcc-4.4 -c print_precisions.adb
gcc-4.4 -c ada_blas-get_precision.ads
gnatbind -x print_precisions.ali
gnatlink print_precisions.ali -lblas

giving

./example1
Dot product is: 0.00000E+00

and

./print_precisions
-- Various BLAS precisions --
Float_Type'Digits: 1
Float_Type'Base'Digits: 6
BLAS precision: SINGLE

Float_Type'Digits: 4
Float_Type'Base'Digits: 6
BLAS precision: SINGLE

Float_Type'Digits: 9
Float_Type'Base'Digits: 15
BLAS precision: DOUBLE

Float_Type'Digits: 13
Float_Type'Base'Digits: 15
BLAS precision: DOUBLE

Float_Type'Digits: 18
Float_Type'Base'Digits: 18
BLAS precision: UNSUPPORTED

-------------

Then I checked the folder /usr/lib/libblas and saw the following:
libblas.a
libblas.so
libblas.so.3gf
libblas.so.3gf.0

and also for /usr/lib/lapack:
liblapack.a
liblapack.so
liblapack.so.3gf
liblapack.so.3gf.0

So now I have the libblas.a and the liblapack.a files!

I didn't create any .bashrc file and didn't do anything with LD_LIBRARY_PATH nor with LIBRARY_PATH.

Thanks again
YC

Simon Wright

unread,
Jul 15, 2012, 6:20:42 PM7/15/12
to
Ada novice <shai...@gmx.com> writes:

> Thank you for the interesting discussions. I finally got BLAS to work.

Very glad to hear it!

Ada novice

unread,
Jul 16, 2012, 3:56:46 AM7/16/12
to
Now I am moving onto testing lapack. In step 11 from Nasser's page:

http://12000.org/my_notes/ada/index.htm

it requires that one has libgfortran.so installed. IS THIS FILE REALLY REQUIRED?

I have made a search on the debian site:

http://www.debian.org/distrib/packages#search_contents

and found for AMD machines:

/usr/lib/gcc/x86_64-linux-gnu/4.3/libgfortran.so gfortran-4.3 [amd64]

(of version 4.3.5-4)

and

/usr/lib/gcc/x86_64-linux-gnu/4.4/libgfortran.so gfortran-4.4 [amd64]

(of version: 4.4.5-8)

I think I will install the version 4.4 as I have gnat-4.4"something".

Please let me know if installing "gfortran" in order to get libgfortran.so is a required step. I currently do not seem to have libgfortran.so already on my machine.


Thanks.
YC

Simon Wright

unread,
Jul 16, 2012, 5:27:16 AM7/16/12
to
Ada novice <shai...@gmx.com> writes:

> Now I am moving onto testing lapack. In step 11 from Nasser's page:
>
> http://12000.org/my_notes/ada/index.htm
>
> it requires that one has libgfortran.so installed. IS THIS FILE REALLY
> REQUIRED?

What you need is the libgfortran.so.3 that lapack was actually linked
against. You only need libgfortran.so if you are going to develop in
Fortran. I can link against liblapack.so without needing gfortran
installed.
Message has been deleted

Ada novice

unread,
Jul 16, 2012, 7:15:40 AM7/16/12
to
More message actions
12:14 PM (1 hour ago)
On Monday, July 16, 2012 10:27:16 AM UTC+1, Simon Wright wrote:

> What you need is the libgfortran.so.3 that lapack was actually linked
> against. You only need libgfortran.so if you are going to develop in
> Fortran. I can link against liblapack.so without needing gfortran
> installed.

libfortran.so.3 then requires the libgfortran3 package. In step 11 from Nasser's page:
http://12000.org/my_notes/ada/index.htm

He created a symlink as libgfortran.so is required. So he links /usr/lib/i386-linux-gnu/libfortran.so to point to /usr/lib/i386-linux-gnu/libgfortran.so.3

What's the difference between the .so and the .so.3 file?

But I am thinking to install the gfortran-4.4 package since then I can test these programs also:

http://www.nag.com/lapack-ex/lapack-ex.html

where example fortran programs are given as well.

I hope that I do not mess things up. Installing gfortran-4-4 will give me libgfortran.so directly and I "will" be able to test example fortran programs as well.


YC

Simon Wright

unread,
Jul 16, 2012, 7:36:42 AM7/16/12
to
Ada novice <shai...@gmx.com> writes:

> On Monday, July 16, 2012 10:27:16 AM UTC+1, Simon Wright wrote:
>
>> What you need is the libgfortran.so.3 that lapack was actually linked
>> against. You only need libgfortran.so if you are going to develop in
>> Fortran. I can link against liblapack.so without needing gfortran
>> installed.
>
> libfortran.so.3 then requires the libfortran2 package.

Not here, it doesn't.

$ ldd /usr/lib/libgfortran.so.3
linux-vdso.so.1 => (0x00007fff8abff000)
libm.so.6 => /lib/libm.so.6 (0x00007f6e351e5000)
libc.so.6 => /lib/libc.so.6 (0x00007f6e34e83000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6e35765000)

> In step 11 from
> Nasser's page:
> http://12000.org/my_notes/ada/index.htm
>
> He created a symlink as libgfortran.so is required. So he links
> /usr/lib/i386-linux-gnu/libfortran.so to point to
> /usr/lib/i386-linux-gnu/libgfortran.so.3

I don't know what went wrong with his installation, but here
libgfortran.so is created when you install gfortran(-4.4). And as
Ludovic has said, don't mess with symlinks in system directories.

> What's the difference between the .so and the .so.3 file?

The .so is a symlink which resolves (eventually) to the actual
file. Here, libgfortran.so.3 is a symlink to libgfortran.so.3.0.0.

$ cd /usr/lib/gcc/x86_64-linux-gnu/4.4.5
$ ls -l libgfortran.so
lrwxrwxrwx 1 root root 25 Jul 16 12:28 libgfortran.so -> ../../../libgfortran.so.3
$ cd ../../..
$ ls -l libgfortran.so.3
lrwxrwxrwx 1 root root 20 Oct 28 2011 libgfortran.so.3 -> libgfortran.so.3.0.0
$ ls -l libgfortran.so.3.0.0
-rw-r--r-- 1 root root 964408 Nov 15 2010 libgfortran.so.3.0.0

> But I am thinking to install the gfortran-4.4 package since then I can
> test these programs also:
>
> http://www.nag.com/lapack-ex/lapack-ex.html
>
> where example fortran programs are given as well.
>
> I hope that I do not mess things up. Installing gfortran-4-4 will give
> me libgfortran.so directly and I "will" be able to test example
> fortran programs as well.

Yes.

Ada novice

unread,
Jul 16, 2012, 9:08:13 AM7/16/12
to
Simon, thanks for your answers. I have problems...

First, I put gfortran-4.4:

pt-cache policy gfortran-4.4
gfortran-4.4:
Installed: 4.4.6-14
Candidate: 4.4.6-14
Version table:
*** 4.4.6-14 0
500 http://debian.linuxmint.com/latest/ testing/main i386 Packages
100 /var/lib/dpkg/status


And then, locate libgfortran gives me:

/usr/lib/gcc/i486-linux-gnu/4.4/libgfortran.a
/usr/lib/gcc/i486-linux-gnu/4.4/libgfortran.so
/usr/lib/gcc/i486-linux-gnu/4.4/libgfortranbegin.a
/usr/lib/i386-linux-gnu/libgfortran.so.3
/usr/lib/i386-linux-gnu/libgfortran.so.3.0.0
/usr/share/doc/libgfortran3
/var/lib/dpkg/info/libgfortran3.list
/var/lib/dpkg/info/libgfortran3.md5sums
/var/lib/dpkg/info/libgfortran3.postinst
/var/lib/dpkg/info/libgfortran3.postrm
/var/lib/dpkg/info/libgfortran3.shlibs
/var/lib/dpkg/info/libgfortran3.symbols

So I have the important libgfortran.a file.

I finished step 10:

http://12000.org/my_notes/ada/index.htm

and in step 11, I do not create any simlink. I replace the existing Makefile in the /lapada/test/interf directory with the one named lapack_interf_makefile.txt (which I rename to Makefile). The file contents are here:

http://12000.org/my_notes/ada/lapack_and_blas/lapack_interf_makefile.txt

Now, when I go in the /lapada/test/interf folder and do a "make all", I get:

make all
gcc -c cxbbase.ads
gcc: error trying to exec 'gnat1': execvp: No such file or directory
make: *** [cxbbase.adb] Error 1

So what is going wrong?

Thanks
YC

Ludovic Brenta

unread,
Jul 16, 2012, 3:51:56 PM7/16/12
to
Ada novice writes on comp.lang.ada:
> make all
> gcc -c cxbbase.ads
> gcc: error trying to exec 'gnat1': execvp: No such file or directory
> make: *** [cxbbase.adb] Error 1

Have you installed gnat?

--
Ludovic Brenta.
Message has been deleted

Ludovic Brenta

unread,
Jul 16, 2012, 5:58:45 PM7/16/12
to
Ada novice writes on comp.lang.ada:
> On Monday, July 16, 2012 8:51:56 PM UTC+1, Ludovic Brenta wrote:
>
>> Have you installed gnat?
>
> Yes sure. I have linux mint Debian and I think the version I installed
> for GNAT was 4.4-5 or something similar. It didn't install the latest
> 4.6.3 version.
>
> But my GNAT is working fine for Ada programs.
>
> And I have also successfully got the bindings to Blas working.
>
> Maybe something in the Makefile? I don't know.

Check again. What is the output of:

dpkg -l gnat
which gcc
gnat -v

?

--
Ludovic Brenta.

Simon Wright

unread,
Jul 16, 2012, 6:14:52 PM7/16/12
to
Ada novice <shai...@gmx.com> writes:

> On Monday, July 16, 2012 8:51:56 PM UTC+1, Ludovic Brenta wrote:
>
>> Have you installed gnat?
>
> Yes sure. I have linux mint Debian and I think the version I installed
> for GNAT was 4.4-5 or something similar. It didn't install the latest
> 4.6.3 version.
>
> But my GNAT is working fine for Ada programs.
>
> And I have also successfully got the bindings to Blas working.
>
> Maybe something in the Makefile? I don't know.

Is there any way that YC's setup could be calling gcc-4.3? because here
GNAT isn't installed on the 4.3 side, only on 4.4.
Message has been deleted
Message has been deleted

Ada novice

unread,
Jul 24, 2012, 9:09:39 AM7/24/12
to
I did a fresh install of GNAT GPL 2011 and took away the GNAT that is packaged for Debian. The latter is problematic on my linux and I cannot explain why.

When I now do which gcc, I get /usr/gnat/bin/gcc

Issuing a gnat -v returns me:
gnat: Unknown command: -v

I have seen many places people using gnat -v but I have never make this work and the documentation doesn't say that -v will give the version of gnat.

I have now also installed gfortran-4.6.

gfortran-4.6 -v
Using built-in specs.
COLLECT_GCC=gfortran-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-1)


and locate libgfortran gives

/usr/lib/gcc/i486-linux-gnu/4.6/libgfortran.a
/usr/lib/gcc/i486-linux-gnu/4.6/libgfortran.so
/usr/lib/gcc/i486-linux-gnu/4.6/libgfortran.spec
/usr/lib/gcc/i486-linux-gnu/4.6/libgfortranbegin.a
/usr/lib/i386-linux-gnu/libgfortran.so.3
/usr/lib/i386-linux-gnu/libgfortran.so.3.0.0
/usr/share/doc/libgfortran3
/var/lib/dpkg/info/libgfortran3.list
/var/lib/dpkg/info/libgfortran3.md5sums
/var/lib/dpkg/info/libgfortran3.postinst
/var/lib/dpkg/info/libgfortran3.postrm
/var/lib/dpkg/info/libgfortran3.shlibs
/var/lib/dpkg/info/libgfortran3.symbols


When I go to Nasser's page at step 11:
http://12000.org/my_notes/ada/index.htm

The makefile now seems to work with gnat but the lgfortran cannot be located:

make all
gcc -c cxbbase.ads
gcc -c cxbbase.ads
gnatmake cxbi.adb -largs ifinc.o -lgfortran -lm
gnatbind -x cxbi.ali
gnatlink cxbi.ali ifinc.o -lgfortran -lm
/usr/gnat/libexec/gcc/i686-pc-linux-gnu/4.5.3/ld: cannot find -lgfortran
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/gnat/bin/gcc
gnatmake: *** link failed.
make: *** [cxbi] Error 4

Anything that I must adjust in my path or something else?


Thanks,
YC

Nasser M. Abbasi

unread,
Jul 24, 2012, 9:54:30 AM7/24/12
to
On 7/24/2012 8:09 AM, Ada novice wrote:

> The makefile now seems to work with gnat but the lgfortran cannot be located:
>
> make all
> gcc -c cxbbase.ads
> gcc -c cxbbase.ads
> gnatmake cxbi.adb -largs ifinc.o -lgfortran -lm
> gnatbind -x cxbi.ali
> gnatlink cxbi.ali ifinc.o -lgfortran -lm
> /usr/gnat/libexec/gcc/i686-pc-linux-gnu/4.5.3/ld: cannot find -lgfortran
> collect2: ld returned 1 exit status
> gnatlink: error when calling /usr/gnat/bin/gcc
> gnatmake: *** link failed.
> make: *** [cxbi] Error 4
>
> Anything that I must adjust in my path or something else?
>
>

As the notes says step 2 on the path:

need to tell the linker where the libraries are. This can be
done either by using -L or by using env. variable LD_LIBRARY_PATH

Does your LD_LIBRARY_PATH point to

/usr/lib/gcc/i486-linux-gnu/4.6

which is where libgfortran.so is?

do echo $LD_LIBRARY_PATH to check before running the makefile

The makefile should really has these build into it where one
can change them and it should use -L and not depend on env. path.
But this is how it was. Will try to improve this when I get
sometime and update the Makefile (I do not like to use env
variables to configure things)

--Nasser

Simon Wright

unread,
Jul 24, 2012, 10:18:33 AM7/24/12
to
Shouldn't that be LIBRARY_PATH?

I thing the trouble is that if you create a Fortran program and compile
it

gfortran foo.f

gfortran knows to include -L/usr/lib/gcc/i486-linux-gnu/4.6 (or
equivalent) when it calls the linker; but other languages don't, so we
have to tell them.

Much the same issue with the Ada RTS, I'd think.
Message has been deleted

Ada novice

unread,
Jul 24, 2012, 10:59:33 AM7/24/12
to
Thanks for your inputs Nasser and Simon.

I put /usr/lib/gcc/i486-linux-gnu/4.6 in LIBRARY_PATH and issuing "make all" now gives:

make all
gcc -c cxbbase.ads
gcc -c cxbbase.ads
gnatmake cxbi.adb -largs ifinc.o -lgfortran -lm
gnatbind -x cxbi.ali
gnatlink cxbi.ali ifinc.o -lgfortran -lm
gnatmake cxbs.adb -largs sfinc.o -lgfortran -lm
gnatbind -x cxbs.ali
gnatlink cxbs.ali sfinc.o -lgfortran -lm
gnatmake cxbd.adb -largs dfinc.o -lgfortran -lm
gnatbind -x cxbd.ali
gnatlink cxbd.ali dfinc.o -lgfortran -lm
gnatmake cxbc.adb -largs cfinc.o -lgfortran -lm
gnatbind -x cxbc.ali
gnatlink cxbc.ali cfinc.o -lgfortran -lm
gnatmake cxbz.adb -largs zfinc.o -lgfortran -lm
gnatbind -x cxbz.ali
gnatlink cxbz.ali zfinc.o -lgfortran -lm
gnatmake cxbch.adb -largs chfinc.o -lgfortran -lm
gnatmake: "cxbch" up to date.
gnatmake cxbsh.adb -largs shfinc.o -lgfortran -lm
gnatmake: "cxbsh" up to date.
gnatmake cxbl.adb -largs lfinc.o -lgfortran -lm
gnatmake: "cxbl" up to date.
gnatmake cxbim.adb -largs imfinc.o -lgfortran -lm
gnatbind -x cxbim.ali
gnatlink cxbim.ali imfinc.o -lgfortran -lm
gnatmake cxbsm.adb -largs smfinc.o -lgfortran -lm
gnatbind -x cxbsm.ali
gnatlink cxbsm.ali smfinc.o -lgfortran -lm
gnatmake cxbdm.adb -largs dmfinc.o -lgfortran -lm
gnatbind -x cxbdm.ali
gnatlink cxbdm.ali dmfinc.o -lgfortran -lm
gnatmake cxbcm.adb -largs cmfinc.o -lgfortran -lm
gnatbind -x cxbcm.ali
gnatlink cxbcm.ali cmfinc.o -lgfortran -lm
gnatmake cxbzm.adb -largs zmfinc.o -lgfortran -lm
gnatbind -x cxbzm.ali
gnatlink cxbzm.ali zmfinc.o -lgfortran -lm
gnatmake cxblm.adb -largs lmfinc.o -lgfortran -lm
gnatbind -x cxblm.ali
gnatlink cxblm.ali lmfinc.o -lgfortran -lm

with no error messages. And testing ./cxbi gives:

$ ./cxbi
Integer number passing:
mode: in out in/out
Ada send:
1 1 1
Fortran get:
1 1 1
Fortran send:
2 2 2
Ada recieve:
1 2 2
Ada send:
-1 -1 -1
Fortran get:
-1 -1 -1
Fortran send:
0 0 0
Ada recieve:
-1 0 0

There are some slight discrepancies in the first and last lines between what is sent and what is received. Is this normal?

In addition I have 2 questions:

1. Do I have to go through step 12 in Nasser's page:

htpp://12000.org/my_notes/ada/index.htm

2. "which gnatmake" will only give me /usr/gnat/bin/gnatmake if I put the latter in the path. But I am not able to write the path once for all. Each time I'm at the terminal, I do:

echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

and then

export PATH=/usr/gnat/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

But this is valid only for the present session.

Can someone indicate me a way just to add /usr/gnat/bin/gnatmake once for all in my path. A basic linux question I guess.


Thanks,
YC

Simon Wright

unread,
Jul 24, 2012, 11:11:48 AM7/24/12
to
Ada novice <shai...@gmx.com> writes:

> with no error messages. And testing ./cxbi gives:
>
> $ ./cxbi
> Integer number passing:
> mode: in out in/out
> Ada send:
> 1 1 1
> Fortran get:
> 1 1 1
> Fortran send:
> 2 2 2
> Ada recieve:
> 1 2 2
> Ada send:
> -1 -1 -1
> Fortran get:
> -1 -1 -1
> Fortran send:
> 0 0 0
> Ada recieve:
> -1 0 0
>
> There are some slight discrepancies in the first and last lines
> between what is sent and what is received. Is this normal?

ISTR there's a comment explaining this at the end of cxbi.adb -
basically, Ada thinks the differing parameters are 'in', so isn't
interested in what the Fortran has set them to (you can get the
equivalent of 'in' parameters in Fortran using 'intents', I think).

Nasser M. Abbasi

unread,
Jul 24, 2012, 11:19:36 AM7/24/12
to
On 7/24/2012 9:18 AM, Simon Wright wrote:

>
> Shouldn't that be LIBRARY_PATH?
>

LIBRARY_PATH will work. But the standard is to use LD_LIBRARY_PATH for
this purpose.

I used, in my notes LIBRARY_PATH to point to /usr/lib/i386-linux-gnu/
only because to find crt1.o which was due to other weird thing
about using libre gnat 2012 and not using gcc gnat. gnatmake wanted to
know where crt1.o was.

see

http://groups.google.com/group/comp.lang.ada/browse_thread/thread/f96b82f9bd22d18a

It happen that, on my box, libgfortran.so was also in /usr/lib/i386-linux-gnu/

BUT you can use LD_LIBRARY_PATH to point to where the .so are. But can't
use LD_LIBRARY_PATH to point it to where crt1.o is !

So, LIBRARY_PATH worked for building in this case.

>locate crt1.o
/usr/lib/i386-linux-gnu/crt1.o

>locate libgfortran.so
/usr/lib/i386-linux-gnu/libgfortran.so

see, they are in the same folder.

---- example -------------------------
>unset LIBRARY_PATH
>export LD_LIBRARY_PATH=/usr/lib/atlas-base/:
/usr/lib/atlas-base/atlas/:
/usr/lib/i386-linux-gnu/

>gnatmake cxblm.adb -largs lmfinc.o -lgfortran -lm

gnatbind -x cxblm.ali
gnatlink cxblm.ali lmfinc.o -lgfortran -lm
/usr/gnat/libexec/gcc/i686-pc-linux-gnu/4.5.4/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/gnat/bin/gcc
gnatmake: *** link failed.
--------------------------------------

You see the error is gnat does not find the crt1.o (not it can't find the .so libs).

Now I add LIBRARY_PATH, which is the SAME as LD_LIBRARY_PATH, and now it works,
since it uses LIBRARY_PATH to find the crt*.o, not the LD_LIBRARY_PATH

---------------------------------
>export LIBRARY_PATH=/usr/lib/i386-linux-gnu/
>gnatmake cxblm.adb -largs lmfinc.o -lgfortran -lm
gnatbind -x cxblm.ali
gnatlink cxblm.ali lmfinc.o -lgfortran -lm
----------------------------------

So, LIBRARY_PATH works to locate crt*.o, but also happend to locate the .so also:

-------------------------------
>unset LD_LIBRARY_PATH
>echo $LD_LIBRARY_PATH

>export LD_LIBRARY_PATH=/usr/lib/atlas-base/:/usr/lib/atlas-base/atlas/
>gnatmake cxblm.adb -largs lmfinc.o -lgfortran -lm
gnatbind -x cxblm.ali
gnatlink cxblm.ali lmfinc.o -lgfortran -lm
---------------------------------

see, now it found libgfortan.so, only becuase it happened to be
in the same folder as crt*.o. On other linux distro's this might not be the case.


> I thing the trouble is that if you create a Fortran program and compile
> it
>
> gfortran foo.f
>
> gfortran knows to include -L/usr/lib/gcc/i486-linux-gnu/4.6 (or
> equivalent) when it calls the linker; but other languages don't, so we
> have to tell them.
>

Yes, it does a shared link in the above, and must be using
ldconf to know the locations of libfortran. On my box, I get

>gfortran foo13.f90
>ldd a.out
linux-gate.so.1 => (0x0092c000)
libgfortran.so.3 => /usr/lib/i386-linux-gnu/libgfortran.so.3 (0x005fb000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x0044c000)
libquadmath.so.0 => /usr/lib/i386-linux-gnu/libquadmath.so.0 (0x00110000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x0076a000)
/lib/ld-linux.so.2 (0x00ddd000)

might be an ldconfig thing. Not sure. It knows where all those things are.

> Much the same issue with the Ada RTS, I'd think.
>

Building things on linux can be confusing sometimes, too many
things in too many places.

--Nasser

Ada novice

unread,
Jul 24, 2012, 11:27:21 AM7/24/12
to n...@12000.org
On Tuesday, July 24, 2012 5:19:36 PM UTC+2, Nasser M. Abbasi wrote:
> I used, in my notes LIBRARY_PATH to point to /usr/lib/i386-linux-gnu/
> only because to find crt1.o which was due to other weird thing
> about using libre gnat 2012 and not using gcc gnat. gnatmake wanted to
> know where crt1.o was.

I had the same problem with GNAT GPL 2011. Then I saw your earlier question (and solution):

>export LIBRARY_PATH=/usr/lib/i386-linux-gnu/

YC

Ada novice

unread,
Jul 24, 2012, 11:40:22 AM7/24/12
to n...@12000.org
In http://12000.org/my_notes/ada/index.htm point 13 where a complete example is given to solve the system Ax=b, on running the code I get an error due to a line almost at the bottom of the code:

for x of b loop

The error message is "too few subscripts in array reference".

The b vector is a 3 rows 1 column vector.

YC

Nasser M. Abbasi

unread,
Jul 24, 2012, 12:41:52 PM7/24/12
to
It works fine here. May be you copied the source from the page wrong.
(I'll make a text file of this later and add it later, for now
you can use the mouse to copy it, it is verbatim text)

--------------------------------
cd lapada/test -- this is where you'll have the test program sit

>gnatmake -gnat2012 -I../ada mysolve.adb
gcc -c -gnat2012 -I../ada mysolve.adb
gnatbind -I../ada -x mysolve.ali
gnatlink mysolve.ali

>ls -lrt
-rwxrwxrwx 1 me me 552678 Jul 24 11:35 mysolve

>./mysolve
-1.31250E+00
3.50000E+00
1.12500E+00

-------------------------

Make sure to copy the source correct. Here it is again

>cat mysolve.adb

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

with Interfaces.Fortran; use Interfaces.Fortran;
with labase; -- from LAPACK binding
with ladrv; -- from LAPACK binding

procedure mySolve is

A: labase.Fortran_Real_Matrix ( 1..3, 1..3 );
b: labase.Fortran_Real_Matrix ( 1..3, 1..1 );
package Real_IO is new Ada.Text_IO.Float_IO( Real );
INFO : Fortran_Integer;
IPIV : labase.Fortran_Integer_Vector ( 1..A'Last(2));

Begin -- solve A x=b

A := ((2.0, 3.0, 1.0),
(2.0, 1.0, 1.0),
(4.0, -1.0, 6.0));

b := (( 1=> 9.0 ),
( 1=> 2.0 ),
( 1=>-2.0 )
);

ladrv.SGESV (N => A'Last(2),
NRHS => b'Last(2),
A => A,
LDA => A'Last(1),
IPIV => IPIV,
B => b,
LDB => b'Last(1),
INFO => INFO);

if ( not(INFO = 0) ) then
raise PROGRAM_ERROR;
end if;

for x of b loop -- print solution
real_io.PUT ( x ); new_line;
end loop;
end mySolve;
--------------------------------------

--Nasser

Ada novice

unread,
Jul 24, 2012, 1:36:27 PM7/24/12
to n...@12000.org
Nasser,

Thanks. I did copy the source code well and I have a printout in front of me and I checked line by line. Anyway, I recopied again and I still get the same error message.

I didn't go through step 12 on your page and the permissions for mysolve.adb in my case are:

-rw-r--r-- 1

These are all the differences that I can find.

YC

Nasser M. Abbasi

unread,
Jul 24, 2012, 6:13:28 PM7/24/12
to
It has to work, if everything done right.

Can you show the actual commands you typed? and the full output.
and also do

cat mysolve.adb

and paste the output. The file protection above
is fine. This will have nothing to do with compile error
any way.

Are you sure you are using libre gnat 2012?

You can't get a compiler error on this source as it compiles
fine with GNAT 2012. There is something else going on.

--Nasser
Message has been deleted

Ada novice

unread,
Jul 25, 2012, 1:04:12 AM7/25/12
to
On Wednesday, July 25, 2012 1:02:35 AM UTC+2, Dennis Lee Bieber wrote:
> It depends on which shell you are running... You need to edit the
> PATH settings in the configuration file of your shell, so it runs at
> log-in
>
> .profile
> .bash-profile (or something like that)
> .bashrc
> .tcshrc
> .shrc

Thanks. After googling last night, I came to realise that this part is not well explained at all to starters in linux. After messing with
/etc/profile
/etc/logindefs
~/.bash_profile
~/.profile
...

I finally got it to work by adding the desired path in .bashrc.

YC

Ada novice

unread,
Jul 25, 2012, 1:36:34 AM7/25/12
to n...@12000.org
First, I am using GNAT GPL 2011 and not the 2012 version. But I am adding the -gnat2012 switch as this is required or else I get:

$ gnatmake -I../ada mysolve.adbgcc -c -I../ada mysolve.adb
mysolve.adb:39:16: iterator is an Ada2012 feature
gnatmake: "mysolve.adb" compilation error

Anyway, back to using the -gnat2012 switch:

(my username here)~/work/ada/testlapack/lapada/test $ gnatmake -gnat2012 -I../ada mysolve.adb
gcc -c -gnat2012 -I../ada mysolve.adb
mysolve.adb:39:21: too few subscripts in array reference
gnatmake: "mysolve.adb" compilation error

and

(my username here)~/work/ada/testlapack/lapada/test $ cat mysolve.adb
I am not convinced to think that using GNAT GPL 2011 instead of the 2012 version is the culprit here. If however I have to change to the 2012 version, I wonder if I can have both the 2011 and 202 on my machine. On windows it is simple as GNAT is stored in year-wise folders.

I am using the 2011 version since there is no in-built lapack/blas in GNAT 2012 and I want to be sure that I can still run the earlier math extension package from Simon Wright.

On Windows installing separate lapack/blas libraries is a nightmare. But I guess if I am using linux, then I can safely change to GPL 2012 and use the updated math extension package from Simon. Anyway, in this respect what is the way to uninstall GNAT GPL 2011 given that this cannot be done via the synaptic package manager since GNAT GPL 2011 does not come pre-packaged for Debian.

Thanks,
YC
Message has been deleted

Nasser M. Abbasi

unread,
Jul 25, 2012, 2:13:00 AM7/25/12
to
On 7/25/2012 12:36 AM, Ada novice wrote:
> First, I am using GNAT GPL 2011 and not the 2012 version.
> But I am adding the -gnat2012 switch as this is required or else I get:
>
> $ gnatmake -I../ada mysolve.adbgcc -c -I../ada mysolve.adb
> mysolve.adb:39:16: iterator is an Ada2012 feature
> gnatmake: "mysolve.adb" compilation error
>
....
>
> I am not convinced to think that using GNAT GPL 2011 instead of the 2012 version is
> the culprit here.

How can you say that?

The construct

for x of b loop -- print solution
real_io.PUT ( x ); new_line;
end loop;

is Ada 2012 ONLY. It also said so in the error message.

mysolve.adb:39:16: iterator is an Ada2012 feature

You are compiling the source code with Ada that does not understand
this construct. Hence the error

mysolve.adb:39:21: too few subscripts in array reference

You can simply for now, change the above LOOP to use standard Ada loop
and not the new enhanced LOOP above, and all will be OK. Or use GNAT 2012
and leave the source as is.

--Nasser

Ada novice

unread,
Jul 25, 2012, 4:56:16 AM7/25/12
to n...@12000.org

> How can you say that?

I was thinking that the -gnat2012 switch should do the trick. Or was this new for loop feature added much later?

So to what extent this -gnat2012 in GPL 2011 is effective?

> You can simply for now, change the above LOOP to use standard Ada loop
> and not the new enhanced LOOP above, and all will be OK. Or use GNAT 2012
> and leave the source as is.

If I modified the for construct to say:

for x in b'Range loop -- print solution
real_io.PUT (x'img); new_line;
end loop;

that doesn't work:

$ gnatmake -gnat2012 -I../ada mysolve2.adb
gcc -c -gnat2012 -I../ada mysolve2.adb
mysolve2.adb:40:21: no candidate interpretations match the actuals:
mysolve2.adb:40:21: missing argument for parameter "Item" in call to "Put" declared at a-tiflio.ads:78, instance at line 11
mysolve2.adb:40:21: missing argument for parameter "Item" in call to "Put" declared at a-tiflio.ads:60, instance at line 11
mysolve2.adb:40:28: expected type "Interfaces.Fortran.Real"
mysolve2.adb:40:28: found type "Standard.String"
mysolve2.adb:40:28: ==> in call to "Put" at a-tiflio.ads:67, instance at line 11
gnatmake: "mysolve2.adb" compilation error

So how to properly output the x vector?

Thanks
YC

Nasser M. Abbasi

unread,
Jul 25, 2012, 5:04:05 AM7/25/12
to
On 7/25/2012 3:56 AM, Ada novice wrote:
>
>> How can you say that?

> If I modified the for construct to say:
>
> for x in b'Range loop -- print solution
> real_io.PUT (x'img); new_line;
> end loop;
>
> that doesn't work:
>

FOR I in b'RANGE(1) LOOP
real_io.put ( b(I,1) ); new_line;
END LOOP;

--Nasser

Ada novice

unread,
Jul 25, 2012, 5:16:06 AM7/25/12
to n...@12000.org
On Wednesday, July 25, 2012 11:04:05 AM UTC+2, Nasser M. Abbasi wrote:
> FOR I in b&#39;RANGE(1) LOOP
> real_io.put ( b(I,1) ); new_line;
> END LOOP;
>

Thanks. This works fine. This was a tough one!

I think that having successfully completed this example means that my lapack and blas (from earlier success) is finally working. Thanks for your patience.

I rather stay with GNAT GPL 2011 for some time as most likely the new 2012 version may still contain bugs. One bug on Windows is that GPS suffers from a memory leak with GNAT GPL 2012. I do not know for Linux and I intend to play safe with the well matured 2011 version.

Thanks,
YC

Martin

unread,
Jul 25, 2012, 5:23:10 AM7/25/12
to n...@12000.org
On Wednesday, July 25, 2012 10:16:06 AM UTC+1, Ada novice wrote:
> On Wednesday, July 25, 2012 11:04:05 AM UTC+2, Nasser M. Abbasi wrote:
> &gt; FOR I in b&amp;#39;RANGE(1) LOOP
> &gt; real_io.put ( b(I,1) ); new_line;
> &gt; END LOOP;
> &gt;
>
> Thanks. This works fine. This was a tough one!
>
> I think that having successfully completed this example means that my lapack and blas (from earlier success) is finally working. Thanks for your patience.
>
> I rather stay with GNAT GPL 2011 for some time as most likely the new 2012 version may still contain bugs. One bug on Windows is that GPS suffers from a memory leak with GNAT GPL 2012. I do not know for Linux and I intend to play safe with the well matured 2011 version.
>
> Thanks,
> YC

Could you not just use GPS 2011 with GNAT 2012?

-- Martin

Georg Bauhaus

unread,
Jul 25, 2012, 5:26:16 AM7/25/12
to
real_io is likely an instance for floating point types.
"x in b'range" means x is of the index type of the array.

'img is a non-Ada extension of GNAT for lazy writers,
intended to be used with pragma Debug. It's result is
of a string type, real_io.Put needs a floating point value.

"x of b" in terms of Ada 2012 means x is of the component
type of b, not of the index type of b. It is what real_io.Put
needs.


--
--
Georg Bauhaus
Y A Time Drain http://www.9toX.de

Ada novice

unread,
Jul 25, 2012, 7:33:36 AM7/25/12
to n...@12000.org
On Wednesday, July 25, 2012 11:23:10 AM UTC+2, Martin wrote:
>
> Could you not just use GPS 2011 with GNAT 2012?

I do not know since I guess the "doinstall" script that comes with gnat gpl will also install its accompanying GPS module unless one modifies the script???

But for a recent discussion topic that I raised:

How to enable Ada with GCC in linux

https://groups.google.com/forum/?fromgroups#!topic/comp.lang.ada/G-5JDGx436Q

it seems that I'm better off installing gnat gpl 2011 in /usr/local/gnat-2011 and then gnat gpl 2012 in /usr/local/gnat-2012. For now I have gnat gpl 2011 in /usr/gnat and I need to get rid of this!

YC

Ada novice

unread,
Jul 25, 2012, 7:37:46 AM7/25/12
to
On Wednesday, July 25, 2012 11:26:16 AM UTC+2, Georg Bauhaus wrote:
....

Thanks for the explanation. I was out of options :) trying to output the float values.

YC

Ada novice

unread,
Jul 25, 2012, 11:37:53 AM7/25/12
to
I have now gnat gpl 2012 in addition to the already installed gnat gpl 2011.

The program mysolve.adb compiles well with gnat 2012 without requiring modification of the for loop as expected. Gnat 2012 can also compiles the modified program that runs under gnat 2011 well as expected also.

The command line for the compilation is

gnatmake -gnat2012 -I../ada mysolve.adb

How can I include this in GPR project for GPS? I know where to put the switch -gnat2012, but what about "-I/.." ?


Thanks,
YC

Ada novice

unread,
Jul 25, 2012, 1:04:22 PM7/25/12
to
Ok, I could add the necessary "../ada" subfolder and make the program run in GPS as well.

YC

Ada novice

unread,
Jul 26, 2012, 3:02:58 PM7/26/12
to
This post started with the ACML library but we digressed and used other lapack/blas libraries instead. Anyway, I would like to report success using the ACML library.

Example files such as "tcgeev.adb" in the lapack binding ran fine and Nasser's example: "mysolve.adb" for solving a system Ax=b from his webpage also ran fine by using say:

gnatmake -gnat2012 -I../ada mysolve.adv -largs -lacml

Apart the lapack/blas library from ACML, the latter also provides fft routines and random number generators. I tried an example fortran fft code in the "examples" folder of ACML and that also worked fine.

Thanks all for your inputs. It has been very worthwhile to learn linux in this adventure as well.

YC
0 new messages