Prev: GUI: Fortran + Visual Basic
Next: Correct way to write a wrapper for C functions that accept/return ?strings
From: Ingo Thies on 9 Mar 2010 04:26
Hi,

I have found a strange behaviour when binding the F90 [1] version of the
SLATEC library [2]. I compiled it using the commands

gfortran -c slatec.f90 [optional optimization]
ar r libslatec90.a slatec.o
thencopy libslatec90.a to a local subfolder /lib.

When compiling program prog.f90 calling this lib, I get messages of
undefined routines:

gfortran prog.f90 -L./lib/ -lslatec90o0 -ladd2sla -o prog.x

../lib//libslatec90.a(slatec.o): In function `dbvder_':
slatec.f90:(.text+0x1a8764): undefined reference to `duivp_'
slatec.f90:(.text+0x1a87a8): undefined reference to `dfmat_'
slatec.f90:(.text+0x1a87ed): undefined reference to `dfmat_'
slatec.f90:(.text+0x1a8820): undefined reference to `dgvec_'
slatec.f90:(.text+0x1a8840): undefined reference to `duvec_'
../lib//libslatec90.a(slatec.o): In function `bvder_':
slatec.f90:(.text+0x235c76): undefined reference to `uivp_'
slatec.f90:(.text+0x235cba): undefined reference to `fmat_'
slatec.f90:(.text+0x235cff): undefined reference to `fmat_'
slatec.f90:(.text+0x235d31): undefined reference to `gvec_'
slatec.f90:(.text+0x235d51): undefined reference to `uvec_'
collect2: ld returned 1 exit status

These message don't occur when using the original F77 version [2] which
is split into individual files. Since on my system there is no
"f90split" utility, I don't see any convenient way to split the files
into individual files which, possibly, may be a solution (but why does
it matter whether the routines are individual files or a single file?)

Any hints?

[1] http://people.sc.fsu.edu/~burkardt/f_src/slatec/slatec.html
[2] http://www.netlib.org/slatec/

The F77 version fails on some of the test programs with "fatal errors"
while the F90 version only produces some minor fails on testing when
using optimisation options (but only in routines that use complex-type
variables). For this reason I want to use the F90 version.

Ingo
From: Louis Krupp on 9 Mar 2010 05:23
Ingo Thies wrote:
> Hi,
>
> I have found a strange behaviour when binding the F90 [1] version of the
> SLATEC library [2]. I compiled it using the commands
>
> gfortran -c slatec.f90 [optional optimization]
> ar r libslatec90.a slatec.o
> thencopy libslatec90.a to a local subfolder /lib.
>
> When compiling program prog.f90 calling this lib, I get messages of
> undefined routines:
>
> gfortran prog.f90 -L./lib/ -lslatec90o0 -ladd2sla -o prog.x
>
> ./lib//libslatec90.a(slatec.o): In function `dbvder_':
> slatec.f90:(.text+0x1a8764): undefined reference to `duivp_'
> slatec.f90:(.text+0x1a87a8): undefined reference to `dfmat_'
> slatec.f90:(.text+0x1a87ed): undefined reference to `dfmat_'
> slatec.f90:(.text+0x1a8820): undefined reference to `dgvec_'
> slatec.f90:(.text+0x1a8840): undefined reference to `duvec_'
> ./lib//libslatec90.a(slatec.o): In function `bvder_':
> slatec.f90:(.text+0x235c76): undefined reference to `uivp_'
> slatec.f90:(.text+0x235cba): undefined reference to `fmat_'
> slatec.f90:(.text+0x235cff): undefined reference to `fmat_'
> slatec.f90:(.text+0x235d31): undefined reference to `gvec_'
> slatec.f90:(.text+0x235d51): undefined reference to `uvec_'
> collect2: ld returned 1 exit status
>
> These message don't occur when using the original F77 version [2] which
> is split into individual files. Since on my system there is no
> "f90split" utility, I don't see any convenient way to split the files
> into individual files which, possibly, may be a solution (but why does
> it matter whether the routines are individual files or a single file?)
>
> Any hints?
>
> [1] http://people.sc.fsu.edu/~burkardt/f_src/slatec/slatec.html
> [2] http://www.netlib.org/slatec/
>
> The F77 version fails on some of the test programs with "fatal errors"
> while the F90 version only produces some minor fails on testing when
> using optimisation options (but only in routines that use complex-type
> variables). For this reason I want to use the F90 version.

From the F77 version of dbvsup.f:

C
C The user must supply subroutines DFMAT, DGVEC, DUIVP and DUVEC,
C when needed (they must be so named), to evaluate the derivative
C as follows
C
C A. DFMAT must be supplied.
C
C SUBROUTINE DFMAT(X,Y,YP)
C X = independent variable (input to DFMAT)
C Y = dependent variable vector (input to DFMAT)
C YP = DY/DX = derivative vector (output from DFMAT)
C
C Compute the derivatives for the homogeneous problem
C YP(I) = DY(I)/DX = MATRIX(X) * Y(I) , I = 1,...,NCOMP
C
C When (NEQIVP .GT. 0) and matrix is dependent on U as
C well as on X, the following common statement must be
C included in DFMAT
C COMMON /DMLIVP/ NOFST
C for convenience, the U vector is stored at the bottom
C of the Y array. Thus, during any call to DFMAT,
C U(I) is referenced by Y(NOFST + I).
....

What's in libadd2sla.a?

How did you link to the F77 version?

Louis
From: jwm on 9 Mar 2010 05:31
On Mar 9, 2:26 am, Ingo Thies <ingo.th...(a)gmx.de> wrote:
> Hi,
>
> I have found a strange behaviour when binding the F90 [1] version of the
> SLATEC library [2]. I compiled it using the commands
>
> gfortran -c slatec.f90 [optional optimization]
> ar r libslatec90.a slatec.o
> thencopy libslatec90.a to a local subfolder /lib.
>
> When compiling program prog.f90 calling this lib, I get messages of
> undefined routines:
>
> gfortran prog.f90 -L./lib/ -lslatec90o0 -ladd2sla -o prog.x
>
> ./lib//libslatec90.a(slatec.o): In function `dbvder_':
> slatec.f90:(.text+0x1a8764): undefined reference to `duivp_'
> slatec.f90:(.text+0x1a87a8): undefined reference to `dfmat_'
> slatec.f90:(.text+0x1a87ed): undefined reference to `dfmat_'
> slatec.f90:(.text+0x1a8820): undefined reference to `dgvec_'
> slatec.f90:(.text+0x1a8840): undefined reference to `duvec_'
> ./lib//libslatec90.a(slatec.o): In function `bvder_':
> slatec.f90:(.text+0x235c76): undefined reference to `uivp_'
> slatec.f90:(.text+0x235cba): undefined reference to `fmat_'
> slatec.f90:(.text+0x235cff): undefined reference to `fmat_'
> slatec.f90:(.text+0x235d31): undefined reference to `gvec_'
> slatec.f90:(.text+0x235d51): undefined reference to `uvec_'
> collect2: ld returned 1 exit status
>
> These message don't occur when using the original F77 version [2] which
> is split into individual files. Since on my system there is no
> "f90split" utility, I don't see any convenient way to split the files
> into individual files which, possibly, may be a solution (but why does
> it matter whether the routines are individual files or a single file?)
>
> Any hints?
>
> [1]http://people.sc.fsu.edu/~burkardt/f_src/slatec/slatec.html
> [2]http://www.netlib.org/slatec/
>
> The F77 version fails on some of the test programs with "fatal errors"
> while the F90 version only produces some minor fails on testing when
> using optimisation options (but only in routines that use complex-type
> variables). For this reason I want to use the F90 version.
>
> Ingo

Those missing dependencies are actually part of slatec_chk, which
might or might not be in the (certainly huge) file you compiled. You
can get the "split version" of slatec (slatec_src) as well as the
slatec_chk from http://netlib.org/slatec .

Or maybe it's just a linker issue. It checks the static libraries for
dependencies only once, unless they're grouped. Try and see if this
works:

gfortran -c prog.f90
gfortran -o prog.x -L./lib/ prog.o -Wl,--start-group -lslatec90o0 -
ladd2sla -Wl,--end-group
From: Ingo Thies on 9 Mar 2010 05:42
Louis Krupp wrote:

> What's in libadd2sla.a?

Only some wrapper routines to make the input more compatible to an
existing program. They do nothing else than call one or more slatec
routines after some re-arrangements of arrays. Just ignore it here.

> How did you link to the F77 version?

In exactly the same way.

Meanwhile, I've tried out the f90split program provided on the parent
page of URL [1] in my posting and split up slatec.f90 into individual
routines (and then moved slatec.f90 out of the way by gzipping it). Now
it works without problems.

That leaves the - now more academical, but still interesting - question
why concatenating the routines into one file causes so much problems.

Ingo
From: John Mansell on 9 Mar 2010 05:32
The problem is due to the monolithic source. The missing routines should
be supplied by the caller, but in your case, I assume the routines
calling the missing routines are not called in your program, so...

You may find Michel Olagnon's f90split useful (it does what it says).

http://www.ifremer.fr/ditigo/molagnon/fortran90/

The Moware-1.0 also gives you a pretty-printer and some others. Even
with a Window operating system, they are useful.


In message <7vmii8FvdeU1(a)mid.individual.net>, Ingo Thies
<ingo.thies(a)gmx.de> writes
>Hi,
>
>I have found a strange behaviour when binding the F90 [1] version of
>the SLATEC library [2]. I compiled it using the commands
>
>gfortran -c slatec.f90 [optional optimization]
>ar r libslatec90.a slatec.o
>thencopy libslatec90.a to a local subfolder /lib.
>
>When compiling program prog.f90 calling this lib, I get messages of
>undefined routines:
>
>gfortran prog.f90 -L./lib/ -lslatec90o0 -ladd2sla -o prog.x
>
>./lib//libslatec90.a(slatec.o): In function `dbvder_':
>slatec.f90:(.text+0x1a8764): undefined reference to `duivp_'
>slatec.f90:(.text+0x1a87a8): undefined reference to `dfmat_'
>slatec.f90:(.text+0x1a87ed): undefined reference to `dfmat_'
>slatec.f90:(.text+0x1a8820): undefined reference to `dgvec_'
>slatec.f90:(.text+0x1a8840): undefined reference to `duvec_'
>./lib//libslatec90.a(slatec.o): In function `bvder_':
>slatec.f90:(.text+0x235c76): undefined reference to `uivp_'
>slatec.f90:(.text+0x235cba): undefined reference to `fmat_'
>slatec.f90:(.text+0x235cff): undefined reference to `fmat_'
>slatec.f90:(.text+0x235d31): undefined reference to `gvec_'
>slatec.f90:(.text+0x235d51): undefined reference to `uvec_'
>collect2: ld returned 1 exit status
>
>These message don't occur when using the original F77 version [2] which
>is split into individual files. Since on my system there is no
>"f90split" utility, I don't see any convenient way to split the files
>into individual files which, possibly, may be a solution (but why does
>it matter whether the routines are individual files or a single file?)
>
>Any hints?
>
>[1] http://people.sc.fsu.edu/~burkardt/f_src/slatec/slatec.html
>[2] http://www.netlib.org/slatec/
>
>The F77 version fails on some of the test programs with "fatal errors"
>while the F90 version only produces some minor fails on testing when
>using optimisation options (but only in routines that use complex-type
>variables). For this reason I want to use the F90 version.
>
>Ingo

--
John Mansell john at wcompsys dot co dot uk

 |  Next  |  Last
Pages: 1 2
Prev: GUI: Fortran + Visual Basic
Next: Correct way to write a wrapper for C functions that accept/return ?strings