Prev: GUI: Fortran + Visual Basic
Next: Correct way to write a wrapper for C functions that accept/return ?strings
From: John Mansell on 9 Mar 2010 06:07
compiling a monolithic source, then putting the .o file in a library
doesn't work how you would desire. ar isn't clever enough to carve the
single .o file up in a per-routine basis. You must do that bit yourself.

If you actually produced an executable with the library derived from
the monolithic source, you may care to compare its size against what you
get now. You would have been getting lots of things that you did not
need (or want).

In message <7vmmvvFo9hU1(a)mid.individual.net>, Ingo Thies
<ingo.thies(a)gmx.de> writes
>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

--
John Mansell john at wcompsys dot co dot uk

From: user1 on 9 Mar 2010 20:12
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.
>
> Ingo


Similar to the comment from jwm ...

I saw similar errors when building a version of slatec.dll from the f77
source, and solved it by pulling the routines from slatec_chk.


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