- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page