Help on how to create a library with F90
Wai Sun Don
However, I ran into the following difficult that I hope someone can give me
some pointer.
I have the following module that was archived into the library, say libjunk.a
Module Junk_Library
USE A
USE B
END Module Junk_Library
A and B are two modules containing all the subroutines of the library.
In the main program, I would USE the Module
Junk_Library in order to
access the subroutines contained in modules A and B
For example,
Program Main
USE Junk_Library
.....
END Program
To create the executable, I compile the program Main and link it
with the library libjunk.a
(without the lib and a, of course.) However, the F90 compiler
would complaint that
it is unable to access the module symbol file for the
module Junk_Library, namely
Junk_Library.mod
which was deleted after the creation of the library libjunk.a
So, in the sense, if I wish to distribute the library, I would
have to also distribute the module symbol
file Junk_Library.mod ? Is there anyway to
get around this problem? If so, How?
Thanks for the info.
-- ..................................................................... Prof. Wai Sun Don, PhD Box F, 182 George Street Div. of Applied Math. Tel : (401)-863-2250 Brown University Fax : (401)-863-1355 Providence, RI 02912
Dan Nagle
Regrettably, this is processor dependent, meaning that the standard
does not specify the file names for module symbol files. Some
vendors use .mod, others .M, others some variation of .o or .obj.
Also, regrettably, there is nothing in the standard which requires
that a module produce a library when compiled. Many compilers
produce a .o or .obj file when compiling a module. Thus, one
may or may not get a selective load when using a module, i.e., one
may have many unused items in the executable.
For more specific advice, please state your compiler/os.
--
Cheers!
Dan Nagle dna...@erols.com
Purple Sage Computing Solutions, Inc.
Wai Sun Don
I am not worry much about any particular OS/compiler. I am using the
xlf90 on the IBM SP2 with RS6000 processor or f90 version 2 on SUN Ultra 1.
I will have a compiled version of the library for each OS/compilers we
are going to support.
Or the user can compile the library with the provided source codes
on their own OS/compiler.
The question that I have is
In order to use the module in the compiled library, the compiler requires
the
module symbol file (Junk_Library.mod) associated with that
particular module (Module_Junk_Library.F90) presented in order to
provide an explicit interface for the calling program (Program Main).
~~~~~~~~~~~~
Without the module symbol file, the compiler would not link the Main
program
with the library. So in the other word, I must distribute the module
symbol file (.mod)
along with the compiled library (lib???.a) together in order for user to
link their
program with the library successfully for a given OS/compiler.
Or is there any other way around this ?
How does IMSL or other F90 library does it?
If I am going in the wrong way in creating a library, what is the better
way?
I am very appreciate for any suggestion/idea that you might have in these
issues...
Dan Nagle wrote:
> Hello,
>
> Regrettably, this is processor dependent, meaning that the standard
> does not specify the file names for module symbol files. Some
> vendors use .mod, others .M, others some variation of .o or .obj.
>
> Also, regrettably, there is nothing in the standard which requires
> that a module produce a library when compiled. Many compilers
> produce a .o or .obj file when compiling a module. Thus, one
> may or may not get a selective load when using a module, i.e., one
> may have many unused items in the executable.
>
Selective Load is not a issue for this library as it is a single purpose
library. Everything must be loaded.
Jan Vorbrueggen
> Without the module symbol file, the compiler would not link the Main program
> with the library. So in the other word, I must distribute the module
> symbol file (.mod) along with the compiled library (lib???.a) together in
> order for user to link their program with the library successfully for a
> given OS/compiler. Or is there any other way around this ?
No. Or do you expect the compiler to read your mind? The module file is the
moral equivalent of a C/C++ .h file, onlt better.
There are, in fact, library implementations that include the necessary
interface definitions within the library themselves. I don't think the
typical Unix archives support this.
Jan
Marco A. Garcia
single file and by themselves (i.e. not being part of a module). Then we
create a module that only contains interfaces for those subroutines that we
want to expose to the end user. We provide end-users with the compiled
module and the library. The user can then USE the module in his/her programs
and link against the library. We like this method because it is easy to
"hide" functions/subroutines that we don't want to expose to the end user
(for example low-level manipulation of matrices), it makes it easier to
manage function and operator overloads, in general seems to make our life
easier when porting to different compilers, and because the user can check
the syntax of the calls to the library at compile time. Of course, this is
just one of many ways to do the same thing.
Regarding your specific question: some compilers generate a .mod (or
whatever name the compiler gives to it) file and a library file. The .mod
file has the symbols; the library file contains the executable code included
in the module. When this is the case, you must distribute both files to your
end users. If the module does not have executable code (for example, if the
module only has interfaces), some compilers only generate a .mod file. Also,
some compilers (in particular f95) put the symbols and the executable code
into a single .mod file. In the last two cases, you only need to provide the
.mod file to your end users.
As Dan Nagle already pointed, there is not a standard for the way compilers
handle module objects, so your best shot is to consult the documentation of
your specific compiler(s).
--
Marco A. Garcia
Canaima Software
1632 Dale Street
San Diego, CA 92102
Tel/Fax: (619) 233-6831
http://www.canaimasoft.com
Developers of f90SQL the database connectivity
library for Fortran, and f90VB the library for seamless
integration of VB and Fortran
Wai Sun Don <ws...@hydra.cfm.brown.edu> wrote in message
news:37D3E8A6...@hydra.cfm.brown.edu...
> I am attempting to create a mathematical library using Fortran 90.
> However, I ran into the following difficult that I hope someone can give
> me
> some pointer.
>
> Thanks for the info.
>
> --
Jan Vorbrueggen
> We like this method because it is easy to "hide" functions/subroutines
> that we don't want to expose to the end user [...]
Isn't that what PUBLIC statements in a MODULE are for? Or doesn one have to
declare all other functions et al. as PRIVATE in addition?
Jan
Marco A. Garcia
internal subroutines in the library created the way I explained before are
still available, they just don't have explicit interfaces in the end-user
module, so the end-user wouldn't know how to call them. When giving
technical support to our products, we find that some times we need to create
a custom subroutine that needs access to our low level procedures in the
library. We can provide the customer with an additional module with the
custom subroutine, we don't need to recompile any of the older modules or
the library. The low level procedures in the library are "sort of hidden",
they are still available to the end user if necessary. This gives a great
deal of flexibility.
--
Marco A. Garcia
Canaima Software
1632 Dale Street
San Diego, CA 92102
Tel/Fax: (619) 233-6831
http://www.canaimasoft.com
Developers of f90SQL the database connectivity
library for Fortran, and f90VB the library for seamless
integration of VB and Fortran
Jan Vorbrueggen <j...@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote in
message news:y4906ig...@mailhost.neuroinformatik.ruhr-uni-bochum.de...