Error in opening the Library module file
Mike
I just create a copy of the same project. The compiling, linking
results of original one is ok.
However, the copied one is not.
The error message shows:
Error: Error in opening the Library module file. [MODA]
Error: Error in opening the Library module file. [MODT]
I use CVF6.6C. I've noticed the the external files are all included
including moda.f90 and modt.f90.
In MODA, I have a subroutine to USE MODT and in MODT, I have a
subroutine to USE MODA.
Two error messages are in some subroutines in MODA and MODT.
In main program I USE:
USE MODA
USE MODT
Sometimes I am suspecting that if the sequence of modules being USEd
matters (I mean first
MODT and the MODA), however, I test it and it doesn't make any
difference.
why is there compiling error if I copy the original project which is
compiled OK?
thank you in advance.
Mike
Mike
module modA
contains
subroutine suba()
use modT
print *,'suba'
end subroutine suba
end module modA
module modT
contains
subroutine subb()
use modA
print *,'subb'
end subroutine subb
end module modT
program main
use modA
use modT
call suba()
call subb()
stop
END
First I compile using CVF6.6C.
The error shows " Error: Error in opening the Library module file.
[MODT]".
Then I interchange the called sequence:
module modT
contains
subroutine subb()
use modA
print *,'subb'
end subroutine subb
end module modT
module modA
contains
subroutine suba()
use modT
print *,'suba'
end subroutine suba
end module modA
Compiled results are OK. NO error. So sequence of module did matter.
Right?
Then I switch to "First modA and then modT" again. Compiled results
are also OK.
I think that's because there are modA.mod and modT.mod now.
Then I intentionally del *.mod. I compiled again.
Error: Error in opening the Library module file. [MODT]
Error: Error in opening the Library module file. [MODA]
No longer OK. Why?
Mike
dpb
Mike wrote:
...
> Then I intentionally del *.mod. I compiled again.
> Error: Error in opening the Library module file. [MODT]
> Error: Error in opening the Library module file. [MODA]
>
> No longer OK. Why?
I'm thinking because you haven't done "Update Dependencies" since you
created the new project and the IDE isn't compiling all out of date
sources--in the case the modules when the .mod files don't exist.
Mike
Same error.
Mike
I delete section of main program and compile.
I get both of them.
Then add section of main program. Done.
Weird.......
Mike
2. I can delete the "use modA" in modT. Then I compile. I have
modT.mod.
Also delete "use modT" in modA. I have also modA.mod.
Then re-input the "use modA" in modT and "use modT" in modA.
Compile. Re-input the main program. Compile it; the results are ok.
I think I can just artificially put two *.mod files to let CVF wake up
to find the *.mod it needs.
I also find some persons also encountering such problems in CVF.
Some responder also suggest to update all dependencies; however, I
tried and
CVF failed to pick up those module files.
Originally they pick up some modules, however, they didn't pick up
modules which
are calling each other. I think this problem is called cyclic
dependencies, right?
Mike
Mike
question.
Jugoslav Dujic
| Mike wrote:
|| Originally they pick up some modules, however, they didn't pick up
|| modules which
|| are calling each other. I think this problem is called cyclic
|| dependencies, right?
Right, "cyclic" or "circular". What you had is (as far as I can tell)
allowed by the standard but it will confuse most compilers -- they
expect the dependency hierarchy to be "tree-like" and cannot tell which
module should be compiled first (esp. when they're in the same source
file).
By all means, try to avoid the situation -- the solution is often
to move the mutually shared stuff to a third module, which is
compilable separately.
Often, the circular dependencies present a design flaw. In other
situations, it's a language flaw (the code you had is, I think,
'correct', but it wouldn't be if USEs are on module tops). Fortran
is apparently designed with strict "top to bottom" hierarchy in
mind (for the good or the bad of it). In some situations, that
forces you to employ a correct top-to-bottom design; in others,
where "circular" design is called for, you have to hack your way
through by some unnatural design choices. I can't tell from your
simple code which is your real case, but there you go...
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
Richard Maine
> Right, "cyclic" or "circular". What you had is (as far as I can tell)
> allowed by the standard but it will confuse most compilers -- they
> expect the dependency hierarchy to be "tree-like" and cannot tell which
> module should be compiled first (esp. when they're in the same source
> file).
No. Cyclic module dependency is not allowed by the standard. Not only is
it a matter of which should be compiled first, but also it is possible
(easy, in fact) for a cyclic dependency to have contradictions. A
trivial example would be a two parameters m and n, with mdefined to
equal n+1 and n defined to equal m+1.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Mike
Jugoslav Dujic wrote:
> Mike wrote:
> | Mike wrote:
> || Originally they pick up some modules, however, they didn't pick up
> || modules which
> || are calling each other. I think this problem is called cyclic
> || dependencies, right?
>
> Right, "cyclic" or "circular". What you had is (as far as I can tell)
> allowed by the standard but it will confuse most compilers -- they
> expect the dependency hierarchy to be "tree-like" and cannot tell which
> module should be compiled first (esp. when they're in the same source
> file).
>
> By all means, try to avoid the situation -- the solution is often
> to move the mutually shared stuff to a third module, which is
> compilable separately.
What's the general idea to avoid it?
Mike
Jugoslav Dujic
| Jugoslav Dujic <jdu...@yahoo.com> wrote:
|
|| Right, "cyclic" or "circular". What you had is (as far as I can tell)
|| allowed by the standard but it will confuse most compilers -- they
|| expect the dependency hierarchy to be "tree-like" and cannot tell which
|| module should be compiled first (esp. when they're in the same source
|| file).
|
| No. Cyclic module dependency is not allowed by the standard. Not only is
| it a matter of which should be compiled first, but also it is possible
| (easy, in fact) for a cyclic dependency to have contradictions. A
| trivial example would be a two parameters m and n, with mdefined to
| equal n+1 and n defined to equal m+1.
Please see Mike's example in post #2 in this thread -- circular USEs
are in contained routines rather than in module declaration sections;
I am aware that cyclic dependency is prohibited in the latter form,
but I'm not sure about the example at hand.
Richard E Maine
> Please see Mike's example in post #2 in this thread -- circular USEs
> are in contained routines rather than in module declaration sections;
> I am aware that cyclic dependency is prohibited in the latter form,
> but I'm not sure about the example at hand.
That is still disallowed. I'm sure I recall some discussion of that
somewhere. Might even have beeen an interp, though I half think it might
have beeen concluded to be "clear enough" (as standard-speak goes) to
not need a formal interp. The language prohibiting the cyclic dependency
doesn't make any distinction between the module specification part and
the contained procedures. It just talks about the module, which includes
both parts equally.
While I don't off-hand think that USEs in the contained routines can get
into the same kind of contradiction as I mentioned in my previous post,
they are still disallowed by the standard.
If one is truly desparate, one workaround for that kind of issue is to
have an external procedure instead of a module one. Perhaps one could
isolate the "problem" by having a module procedure that called the
external one. I've been tempted by that approach and might even have
temporarily hacked some code like that, but in the end, I've always
taken a different approach, perhaps reorganizing things. I think that
the "always" is literally true there; anyway, I can't off-hand think of
any exceptions that I left in production code.
I'll note that a solution for some common cases is in the submodule
stuff of the f2003 submodules TR (not f2003 itself, but the TR that came
out essentially simultaneously with f2003 and is being implemented be
some vendors in advance of f2003 itself). I would not claim that
submodules address all such problems, but they do address one major
cause of this kind of issue. I personally view submodules as a way to
have a dependency relationship other than a tree - specifically to
reverse the dependency at some points, having "low-level"
implementations depend on "high-level" interface specifications rather
than the other way around.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Mike
to move the mutually shared stuff to a third module, which is
compilable separately".
So, how to avoid cyclic dependency before making mistake?
Yes. The solution is also what Jugoslav said.
But when I write a new subroutine/function with some many USEd
modules, do I really need to
see the dependencies ? It's quite troublesome.
Mike
Jugoslav Dujic
"Weeks of coding can save you hours of planning".
While the maxim is ironical indeed, the point is that you have to
think about the problem in advance and DESIGN the software before
you start throwing code at it. That means creating a general
overview of "blocks" (modules/source files), each dedicated to doing
one particular thing, then drawing dependencies between them, creating
a dependency tree and anticipate the problems in advance (so that you
don't end up in the situation like the one you describe). Only then,
you can start coding -- some prefer "top-to-bottom" (rough outline
of the algorithm first, then gory details in "low-level" modules),
others "bottom-to-top", (like assembling Lego puzzles).
But sorry, I can't give you an intelligent answer as to how to
solve that particular problem -- I simply don't have enough data.
We don't know what is the exact problem that is supposed to be
solved. Can you briefly state the kind of problem you're trying to
solve and/or post some actual code?