Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Using modules in a static-library

vriesdwj
Beginner
626 Views
Hi,

I have some sources in which the same module is "USED".
So, sources a and b both use module c.
To hand over the code to someone else I want to build a static library of source a, because he is not supposed to change things in that code. That's no problem whenever I compile a and c both. ==> a.lib
To build an executable from b I now need the source of b, the source of c and a.lib (in which c already is included).
Is this correct?
Can the other user change c without problems for my library a?

Regards, Wilco de Vries.
0 Kudos
1 Reply
Ron_Green
Moderator
626 Views
Without an example, it's a little hard to figure out. But I think I'll try:

to build executable: you need the b.f90, a.lib, a.mod, c.mod and c.obj. You won't need the sources for c.f90 nor a.f90. Compile line to look like
ifort -c c.f90
ifort -c a.f90
del a.f90
lib /out:a.lib a.obj c.obj
!you do include c's object in a.lib, yes? If not, this changes things
ifort b.f90 a.lib

can the user change c: no, the object for c is in a.lib, so you should not change it, or if you do change it, rebuild a.lib using a.obj, the new c.obj and module files a.mod and c.mod.

IF you don't put the c.obj in a.lib, then you have a different problem:

ifort -c c.f90
ifort -c a.f90
del a.f90
lib /out:a.lib a.obj
ifort b.f90 a.lib c.obj

...change c.f90, ifort -c c.f90
ifort b.f90 a.lib c.obj

<- big problems if you changed the interfaces, symbols, etc. in c.f90. Link errors or runtime errors. Very ill-advised. IF you carefully change c.f90 to not touch the interfaces and public symbols you may just get away with it. I wouldn't gamble on users being that smart and careful. Bad bet.

ron
0 Kudos
Reply