Hi all.

I have a question about compiling programs using a precompiled library.

One example: I am using the SLATEC library (F90 version) that has been 
compiled to a libslatec.a archive. One of my additional subprograms 
calls routines from there. The standard way to compile is

main: $(MAIN)
	$(F90) -L[path]lslatec90 -o main.x $(MAIN)

where $(MAIN) contains a number of program-specific subroutines. One of 
these, as mentioned, does calls to SLATEC itself.

The problem now is that the objects called from those subroutines are 
not recognized. I guess that I have to (pre) compile this routine with a 
separate reference to SLATEC rather than in the final statement. Since I 
am not too experiences with nested references inside a Makefile, my 
question ist, how to do this properly.

A related question is, how to include modules into a library. I always 
get an error message about non-existing .mod files, even if they are 
included in the .a library file.

Thanks in advance for any helpful answer, and sorry, if this is a 
frequently-asked question, but at least Google doesn't find appropriate 
hits.

Ingo

On 2011-04-26 11:36, I wrote:

> main: $(MAIN)
> $(F90) -L[path]lslatec90 -o main.x $(MAIN)

OK, there was a syntax error, it must be -L[path] -lslatec90, so this 
resolved the slatec issue.

However, there remains the question about modules in libraries (thus the 
subject line). For example, I tried to include a self-written routine 
with its own module into a .a library file, but the module, which is 
being referenced to from the main program, is not recognized, even if 
the .mod file itself is included into the .a library file. I guess there 
must be some special option to do this properly, or are .a libraries not 
well-suited for modules at all?


Ingo

In article <91niraFah1U1@mid.individual.net>, Ingo Thies
<ingo.thies@gmx.de> writes: 

> However, there remains the question about modules in libraries (thus the 
> subject line). For example, I tried to include a self-written routine 
> with its own module into a .a library file, but the module, which is 
> being referenced to from the main program, is not recognized, even if 
> the .mod file itself is included into the .a library file. I guess there 
> must be some special option to do this properly, or are .a libraries not 
> well-suited for modules at all?

I don't know much about Fortran on unix, but on other operating systems
with OBJECT libraries, it is of course no problem to link against the
object library in order to access the compiled routines there.  Fortran
MODULES are a completely different issue.  I suspect there is a
command-line option to tell it where to look (directory, path etc), 
similar to the mechanism for finding INCLUDE files.  Note that the 
module needs to be accessed during compiling, while the object library 
is accessed during linking.

Am 2011-04-26 13:00, schrieb Phillip Helbig---undress to reply:

> similar to the mechanism for finding INCLUDE files.  Note that the
> module needs to be accessed during compiling, while the object library
> is accessed during linking.

For this reason, I normally avoid all the issues with precompiled 
libraries by writing the required file paths into a separate 
includelist.f file and putting it along with the modules at the 
beginning of the list of objects. But when using slatec of lapack, 
making an includelist with all the dependencies is a pain...

I thought there would be a way to make the library contents available on 
compilation, so that including the *.mod would be sufficient.

-- 
Gru�,
       Ingo

On 04/26/2011 11:50 AM, Ingo Thies wrote:
> On 2011-04-26 11:36, I wrote:
> 
>> main: $(MAIN)
>> $(F90) -L[path]lslatec90 -o main.x $(MAIN)
> 
> OK, there was a syntax error, it must be -L[path] -lslatec90, so this
> resolved the slatec issue.
> 
> However, there remains the question about modules in libraries (thus the
> subject line). For example, I tried to include a self-written routine
> with its own module into a .a library file, but the module, which is
> being referenced to from the main program, is not recognized, even if
> the .mod file itself is included into the .a library file. I guess there
> must be some special option to do this properly, or are .a libraries not
> well-suited for modules at all?

..o object files and resulting .a libraries are simply orthogonal to the module
syntax typically stored in .mod files. To compile with .mod files in some
directory /foo/bar you need to give the corresponding module path flag to your
compiler. In many cases -I doubles for this purpose (while also setting the path
for includes) but that is not universal, as is the .mod suffix.

The resolution of symbols is then entirely up to the link editor, which knows
about neither C nor Fortran (though I think many systems have some special magic
for C++).

Your problems (you didn't really show your error message so I can only guess)
most likely are because you messed up the link line: if a depends on b (like in
your example $(MAIN) contains something depending on libslatec90), then a has to
be left of b on the link editor call. I.e. changing your recipe to

main: $(MAIN)
	$(F90) -o main.x $(MAIN) -L[path] -lslatec90

might improve your situation.

Greetings, Thomas

Hello,

Ingo Thies wrote:
> Hi all.
> 
> I have a question about compiling programs using a precompiled library.
> 
[example with syntax error snipped]

> A related question is, how to include modules into a library. I always
> get an error message about non-existing .mod files, even if they are
> included in the .a library file.

The .mod files are separate from the .a

I put static libraries (*.a) in a /lib directory and all the associated *.mod files in a /include directory. My
makefiles contain (using my fft library as an example):

INCLUDES = -I$(FFT_LIB)/include
LIBRARIES = -L$(FFT_LIB)/lib -lfft

FC_FLAGS= -c \
          ...etc...
          ${INCLUDES}
FL_FLAGS= ${LIBRARIES} \
          -o

..SUFFIXES: .F90 .f90 .o
..F90.o:
        $(FC) $(EXTRA_FC_FLAGS) $(FC_FLAGS) $(FPP_FLAGS) $<

..f90.o:
        $(FC) $(EXTRA_FC_FLAGS) $(FC_FLAGS) $<


The "-I" compiler switch tells the compiler to search that directory for *.mod files. It appears to be relatively common
across compilers but you may need to use a different switch for your compiler.

cheers,

paulv

Ingo Thies <ingo.thies@gmx.de> wrote:

> I thought there would be a way to make the library contents available on
> compilation, so that including the *.mod would be sufficient.

No. Libraries are accessed only during linking (at least with the usual
implementations). The .mod files are used only during compilation (and
not during linking).

However, the handling of .mod files isn't fundamentally any harder than
the object files. It is prettty parallel in many ways. If you are
finding it much harder, then something is amiss. Just like you collect
the .o files into a .a library, collect the .mod files ino a directory.
You don't have to leave them where they were originally created. It
doesn't take much abstraction at all to even think of the directory as a
kind of file (heck, it basically is). 

Then, just like there are the -L and -l command-line options to tell the
linker where to get librares, there is usually the -I option to tell the
compiler where to get the .mod files (at least those are the most common
option names). 

That should take care of finding them. Doing compilations in the right
order so that modules are compiled before you use them is really an
unrelated matter and takes more work. That's where dependencies come up.
There are several utilities for automatically maintaining the dependency
information. I used to use makedepf90.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

First of all,

thank you all for your replies. I will experiment with your and 
Richard's advice.

Am 2011-04-26 14:05, schrieb Thomas Jahns:

> Your problems (you didn't really show your error message so I can only guess)
> most likely are because you messed up the link line: if a depends on b (like in
> your example $(MAIN) contains something depending on libslatec90), then a has to
> be left of b on the link editor call. I.e. changing your recipe to
>
> main: $(MAIN)
> 	$(F90) -o main.x $(MAIN) -L[path] -lslatec90

The funny thing is, that putting the -L stuff left of the $(main) thing 
actually works on Mac OS-X, but doesn't on Linux. However, treatment of 
the modules requires different treatment (as Richard et al. mentionet) 
in either way.

Since there are only few modules, I am treating them now simply in-line 
(with the modules files on the left-hand side of the calling programs, 
otherwise it won't work), as one would naturally do, and do not put the 
auxiliary routines into a library (this would be a library besides slatec).

So far,

Ingo