ARPACK test case for configure.ac

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

ARPACK test case for configure.ac

Rik-4
12/26/11

John,

I reduced the work you did in bug #31479 to a simple test case that could
be run by configure to verify the installed ARPACK library.  I'm attaching
the file as you can probably insert it more easily into configure.ac.

When I run
g++ -o arpack_libtest -llapack -lblas -larpack arpack_libtest.cc
./arpack_libtest

I get a segfault.  This is built against a problem version of ARPACK that
is shipped with Ubuntu 10.04 (2.1+parpack96.dfsg-2build1).

If I build against the fixed version of ARPACK in libcruft it works

g++ -o arpack_libtest -L/usr/local/lib/octave/3.4.3 -llapack -lblas -lcruft
arpack_libtest.cc
setenv LD_LIBRARY_PATH /usr/local/lib/octave/3.4.3/
./arpack_libtest

--Rik


arpack_libtest.cc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ARPACK test case for configure.ac

marco atzeri-2
On 12/27/2011 12:21 AM, Rik wrote:

> 12/26/11
>
> John,
>
> I reduced the work you did in bug #31479 to a simple test case that could
> be run by configure to verify the installed ARPACK library.  I'm attaching
> the file as you can probably insert it more easily into configure.ac.
>
> When I run
> g++ -o arpack_libtest -llapack -lblas -larpack arpack_libtest.cc
> ./arpack_libtest

to compile correctly on windows platforms, the order should be:

g++ arpack_libtest.cc -o arpack_libtest -larpack -llapack -lblas

the test passes on latest cygwin arpack-3.0.1-1
./arpack_libtest


>
> I get a segfault.  This is built against a problem version of ARPACK that
> is shipped with Ubuntu 10.04 (2.1+parpack96.dfsg-2build1).
>
> If I build against the fixed version of ARPACK in libcruft it works
>
> g++ -o arpack_libtest -L/usr/local/lib/octave/3.4.3 -llapack -lblas -lcruft
> arpack_libtest.cc
> setenv LD_LIBRARY_PATH /usr/local/lib/octave/3.4.3/
> ./arpack_libtest
>
> --Rik
>

Reply | Threaded
Open this post in threaded view
|

ARPACK sources removed from Octave (was: ARPACK test case for configure.ac)

John W. Eaton
Administrator
In reply to this post by Rik-4
On 26-Dec-2011, Rik wrote:

| I reduced the work you did in bug #31479 to a simple test case that could
| be run by configure to verify the installed ARPACK library.  I'm attaching
| the file as you can probably insert it more easily into configure.ac.
|
| When I run
| g++ -o arpack_libtest -llapack -lblas -larpack arpack_libtest.cc
| ./arpack_libtest
|
| I get a segfault.  This is built against a problem version of ARPACK that
| is shipped with Ubuntu 10.04 (2.1+parpack96.dfsg-2build1).
|
| If I build against the fixed version of ARPACK in libcruft it works
|
| g++ -o arpack_libtest -L/usr/local/lib/octave/3.4.3 -llapack -lblas -lcruft
| arpack_libtest.cc
| setenv LD_LIBRARY_PATH /usr/local/lib/octave/3.4.3/
| ./arpack_libtest

Thanks for looking at this problem.  I converted your C++ program to
Fortran and checked in the following changeset to add the test to the
configure script and remove the arpack sources from Octave.

  http://hg.savannah.gnu.org/hgweb/octave/rev/834df9f10963

Could you check to make sure that this test still fails when you run
it with the old version of ARPACK that has the bug?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ARPACK sources removed from Octave (was: ARPACK test case for configure.ac)

tmacchant
Hello

I have gotten stable branch source by
hg update --clean stableat the 'stable' directory.
There is not arpack directory in stable/libcruft.

However, I have created clone by
rm -rf ./stable-work
hg clone ./stable ./stable-work

In the stable-work, I can find stable-work/libcruft/arpack.

Is the above correct behavior?

Am I wrong in the operation?

Regards

Tatsuro

--- On Wed, 2012/1/4, John W. Eaton wrote:

> On 26-Dec-2011, Rik wrote:
>
> | I reduced the work you did in bug #31479 to a simple test case that could
> | be run by configure to verify the installed ARPACK library.  I'm attaching
> | the file as you can probably insert it more easily into configure.ac.
> |
> | When I run
> | g++ -o arpack_libtest -llapack -lblas -larpack arpack_libtest.cc
> | ./arpack_libtest
> |
> | I get a segfault.  This is built against a problem version of ARPACK that
> | is shipped with Ubuntu 10.04 (2.1+parpack96.dfsg-2build1).
> |
> | If I build against the fixed version of ARPACK in libcruft it works
> |
> | g++ -o arpack_libtest -L/usr/local/lib/octave/3.4.3 -llapack -lblas -lcruft
> | arpack_libtest.cc
> | setenv LD_LIBRARY_PATH /usr/local/lib/octave/3.4.3/
> | ./arpack_libtest
>
> Thanks for looking at this problem.  I converted your C++ program to
> Fortran and checked in the following changeset to add the test to the
> configure script and remove the arpack sources from Octave.
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/834df9f10963
>
> Could you check to make sure that this test still fails when you run
> it with the old version of ARPACK that has the bug?
>
> jwe
>
Reply | Threaded
Open this post in threaded view
|

Re: ARPACK sources removed from Octave

Rik-4
In reply to this post by John W. Eaton
On 01/03/2012 05:18 PM, John W. Eaton wrote:

> On 26-Dec-2011, Rik wrote:
>
> | I reduced the work you did in bug #31479 to a simple test case that could
> | be run by configure to verify the installed ARPACK library.  I'm attaching
> | the file as you can probably insert it more easily into configure.ac.
> |
> | When I run
> | g++ -o arpack_libtest -llapack -lblas -larpack arpack_libtest.cc
> | ./arpack_libtest
> |
> | I get a segfault.  This is built against a problem version of ARPACK that
> | is shipped with Ubuntu 10.04 (2.1+parpack96.dfsg-2build1).
> |
> | If I build against the fixed version of ARPACK in libcruft it works
> |
> | g++ -o arpack_libtest -L/usr/local/lib/octave/3.4.3 -llapack -lblas -lcruft
> | arpack_libtest.cc
> | setenv LD_LIBRARY_PATH /usr/local/lib/octave/3.4.3/
> | ./arpack_libtest
>
> Thanks for looking at this problem.  I converted your C++ program to
> Fortran and checked in the following changeset to add the test to the
> configure script and remove the arpack sources from Octave.
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/834df9f10963
>
> Could you check to make sure that this test still fails when you run
> it with the old version of ARPACK that has the bug?
>
> jwe
>
Alas, the new test does not fail with a bad ARPACK library.  Is there a
reason to have the test written in Fortran and not C++?  The C++ version
was already debugged, but if we really want the configure test in Fortran
we can continue.

I wrapped your test code with "program main" / "end program main" to make
it a stand-alone program.  The file is attached.

I compile with
gfortran -o fortran_libtest arpack_libtest.f -llapack -lblas -larpack

and then run
./fortan_libtest

which returns to the shell prompt normally.

--Rik

arpack_libtest.f (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ARPACK sources removed from Octave

John W. Eaton
Administrator
On  4-Jan-2012, Rik wrote:

| Alas, the new test does not fail with a bad ARPACK library.  Is there a
| reason to have the test written in Fortran and not C++?  The C++ version
| was already debugged, but if we really want the configure test in Fortran
| we can continue.

I did it to avoid issues of portability when mixing Fortran and C++.
For example, you appended underscores to the Fortran names, but not
all compilers do that.  You also used lower-case names, but some
Fortran compilers use translate the Fortran function names to upper
case.  Then there are different conventions for passing character
strings.  So to make the test work for all Fortran compilers that
might be used to compile ARPACK, we need to handle those issues.  It
seemed simpler to just avoid all that and use an all Fortran test.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ARPACK sources removed from Octave

John W. Eaton
Administrator
On  4-Jan-2012, John W. Eaton wrote:

| On  4-Jan-2012, Rik wrote:
|
| | Alas, the new test does not fail with a bad ARPACK library.  Is there a
| | reason to have the test written in Fortran and not C++?  The C++ version
| | was already debugged, but if we really want the configure test in Fortran
| | we can continue.
|
| I did it to avoid issues of portability when mixing Fortran and C++.
| For example, you appended underscores to the Fortran names, but not
| all compilers do that.  You also used lower-case names, but some
| Fortran compilers use translate the Fortran function names to upper
| case.  Then there are different conventions for passing character
| strings.  So to make the test work for all Fortran compilers that
| might be used to compile ARPACK, we need to handle those issues.  It
| seemed simpler to just avoid all that and use an all Fortran test.

I thought about this some more and realized that there are three major
calling conventions for character arguments that we ever tried to
support: f2c, Cray/Unicos, and MSVF (look in libcruft/misc/f77-fcn.h).
Cray/Unicos is probably not a major issue now.  I don't know that MSVF
was ever tested.  We don't have a configure test to enable it
automatically.  So I checked in the following change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/71e28fda7be9

It causes a configure failure on my Debian system that disables
ARPACK.  Testing your program by hand and linking it with the ARPACK
library that we were previously distributing works, so I think the
test is OK.

Now the question is whether distributions will package the new ARPACK
library so that Octave will be fully functional.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ARPACK sources removed from Octave

bpabbott
Administrator
On Jan 5, 2012, at 12:22 AM, John W. Eaton wrote:

> On  4-Jan-2012, John W. Eaton wrote:
>
> | On  4-Jan-2012, Rik wrote:
> |
> | | Alas, the new test does not fail with a bad ARPACK library.  Is there a
> | | reason to have the test written in Fortran and not C++?  The C++ version
> | | was already debugged, but if we really want the configure test in Fortran
> | | we can continue.
> |
> | I did it to avoid issues of portability when mixing Fortran and C++.
> | For example, you appended underscores to the Fortran names, but not
> | all compilers do that.  You also used lower-case names, but some
> | Fortran compilers use translate the Fortran function names to upper
> | case.  Then there are different conventions for passing character
> | strings.  So to make the test work for all Fortran compilers that
> | might be used to compile ARPACK, we need to handle those issues.  It
> | seemed simpler to just avoid all that and use an all Fortran test.
>
> I thought about this some more and realized that there are three major
> calling conventions for character arguments that we ever tried to
> support: f2c, Cray/Unicos, and MSVF (look in libcruft/misc/f77-fcn.h).
> Cray/Unicos is probably not a major issue now.  I don't know that MSVF
> was ever tested.  We don't have a configure test to enable it
> automatically.  So I checked in the following change:
>
>  http://hg.savannah.gnu.org/hgweb/octave/rev/71e28fda7be9
>
> It causes a configure failure on my Debian system that disables
> ARPACK.  Testing your program by hand and linking it with the ARPACK
> library that we were previously distributing works, so I think the
> test is OK.
>
> Now the question is whether distributions will package the new ARPACK
> library so that Octave will be fully functional.
>
> jwe


Using arpack from macports, I built and tested using stable. Everything works as expected.

        https://trac.macports.org/browser/trunk/dports/math/arpack/Portfile

For reference, Macports builds arpack using the sources from Scilab.

        http://forge.scilab.org/index.php/p/arpack-ng

Ben

Reply | Threaded
Open this post in threaded view
|

Re: ARPACK sources removed from Octave

marco atzeri-2
On 1/5/2012 4:15 PM, Ben Abbott wrote:

>
> Using arpack from macports, I built and tested using stable. Everything works as expected.
>
> https://trac.macports.org/browser/trunk/dports/math/arpack/Portfile
>
> For reference, Macports builds arpack using the sources from Scilab.
>
> http://forge.scilab.org/index.php/p/arpack-ng
>
> Ben
>

everything is fine also for cygwin.

$ cygcheck -c -d |grep arpack
libarpack-devel                3.0.1-1
libarpack0                     3.0.1-1

now eigs.oct depends on cygarpack-0.dll

Regards
Marco
Reply | Threaded
Open this post in threaded view
|

Re: ARPACK sources removed from Octave

Rik-5
In reply to this post by bpabbott
On 01/05/2012 07:15 AM, Ben Abbott wrote:
>



> Using arpack from macports, I built and tested using stable.

Everything works as expected.



>



>

https://trac.macports.org/browser/trunk/dports/math/arpack/Portfile



>



> For reference, Macports builds arpack using the sources from

Scilab.



>



> http://forge.scilab.org/index.php/p/arpack-ng



>



> Ben


The test works correctly on Kubuntu 10.04.  Using the default ARPACK installed by the package manager causes the test to fail and Octave is built without eigs support.  I downloaded arpack-ng and installed that in /usr/local and the configure test then passes and successfully builds with eigs support.  Owing to the vagaries of ldconfig I needed to remove the package manager version of ARPACK before this would work which is advice we might want to pass along.

Should we make a note in the NEWS file that ARPACK, which was added in the 3.4.X series, has now been removed?  Should we point users to arpack-ng until the distributions get around to building a good copy of ARPACK?

--Rik