Help on how to create a library with F90

505 views
Skip to first unread message

Wai Sun Don

unread,
Sep 6, 1999, 3:00:00 AM9/6/99
to
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.

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

unread,
Sep 6, 1999, 3:00:00 AM9/6/99
to
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.

For more specific advice, please state your compiler/os.

--

Cheers!
Dan Nagle dna...@erols.com
Purple Sage Computing Solutions, Inc.

Wai Sun Don

unread,
Sep 6, 1999, 3:00:00 AM9/6/99
to
Thank you for your reply.

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

unread,
Sep 7, 1999, 3:00:00 AM9/7/99
to
Wai Sun Don <ws...@hydra.cfm.brown.edu> writes:

> 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

unread,
Sep 7, 1999, 3:00:00 AM9/7/99
to
What we usually do is to group all the library functions/subroutines in a
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

unread,
Sep 7, 1999, 3:00:00 AM9/7/99
to
"Marco A. Garcia" <mga...@canaimasoft.com> writes:

> 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

unread,
Sep 7, 1999, 3:00:00 AM9/7/99
to
Yes, but as I said, there are several ways to achieve the same result. The
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...

Reply all
Reply to author
Forward
0 new messages