Vladimír Fuka wrote:
> I have a question regarding clash of modules with the same name.
>
> module some_common_name
> parameter (a=1.)
> end module
>
> module library
> use some_common_name
> end module
I would advice to avoid it - even if it works - or seems to work. In
particular, if it works, it still can be confusing!
In terms of clashes, it depends on which information is stored where -
and how you link.
a) Publicly visible symbol in the .o file: If you have a same-named
module procedure/module variable, they get the same name mangling. If
you directly link the .o files, you will get an error as the same symbol
is declared multiple times. With library linking, you might get away as
your own (*.o) implementation might have a higher precedence than the
library. (But at runtime you might access the wrong procedure/variable.
This is often used - with weak alias - to allow to link optimized math
functions while they are also in the libm library.)
b) Debugging symbols: They allow to access "print module::var". Except
for being confusing, it shouldn't matter much.
c) Information from the ".mod" files. Either the .mod file contains all
public information from the .mod files the module uses, or just
references to such a .mod file. In particular, the latter is likely to
fail: If you need symbol "foo" from the libraries' "some_common_name"
but the compiler opens the some_common_name.mod of your program, it
might not find the information. (Some compilers also store this
information in the .o file directly instead of using a separate .mod file.)
> In my case the workaround that made it work also in Intel was to do
>
> module library
> use some_common_name, a => a
> end module
>
> because that includes the information about a inside library.mod, as
> others do by default
Don't rely that other compilers won't change or that all compilers do
then include all information rather than only the rename list.
> Can this standard conforming, or not? Is it better to manually
> name-mangle all modules in a library code?
From the standard: "The name of a common block with no binding label,
external procedure with no binding label, or program unit that is not a
submodule is a global identifier. [...] The global identifier of an
entity shall not be the same as the global identifier of any other
entity." (F2008, 16.2 Global identifiers)
With "1.3.116 program unit: main program, external subprogram, module,
submodule, or block data program unit (2.2.1)".
In any case, even if it were standard conforming, practice shows that it
does not work reliably. Thus, renaming either the modules of the library
or the ones of the program seems to be the best solution.
Tobias