Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Modules with the same name

43 views
Skip to first unread message

\"Vladimír Fuka <"name.surnameat

unread,
Jan 4, 2013, 4:30:40 AM1/4/13
to
I have a question regarding clash of modules with the same name.

I have an example, that is compilable with gfortran and oracle, but fails
with intel. My feeling is that it may be just a coincidence it does not
fail badly in the other cases.

Let's consider a shared library, that consists of a hierarchy of modules,
one of which (not the top one) is named some_common_name. However, the top
one uses this module end exports its symbols.

module some_common_name
parameter (a=1.)
end module

module library
use some_common_name
end module

lib> ifort -shared lib.f90 -o library.s

This library (in binary form) is used by a different programmer in his
program in which he uses a different module named some_common_name. Is
this possible? What if there are different public variables with the same
name in those modules?


program prog
use some_common_name !different one
use library

implicit none

print *,a
end program

prog> ifort prog.f90 -I../lib -L../lib -lrary

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


Can this standard conforming, or not? Is it better to manually name-mangle
all modules in a library code?

Vladimir

Tobias Burnus

unread,
Jan 4, 2013, 5:08:24 AM1/4/13
to
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

glen herrmannsfeldt

unread,
Jan 4, 2013, 7:32:29 AM1/4/13
to
\"Vladimír Fuka <\"name.surname at <mffDOTcuniDOTcz">> wrote:
> I have a question regarding clash of modules with the same name.

> I have an example, that is compilable with gfortran and oracle, but fails
> with intel. My feeling is that it may be just a coincidence it does not
> fail badly in the other cases.

> Let's consider a shared library, that consists of a hierarchy of modules,
> one of which (not the top one) is named some_common_name. However, the top
> one uses this module end exports its symbols.

If I understand the question, this is why Java has packages.

Using packages adds additional levels of name qualification such that
names won't conflict. Using import (similar to use) allows one to use
names without extra qualification when they are unique.

(The Java convention is for an organization to use its domain name
with the components in the reverse order, such as com.sun, to qualify
the package name.)

If you import the top level, (not conflicting) then you can reference
it without full qualification. The lower level routines inside the
package will be qualified, such that there is no conflict.

If there is conflict at the top level, then you have to fully
qualify everything.

It is usual to

import java.io.*;
import java.util.*;

which allows using the standard Java packages without the extra
qualification that would otherwise be needed.

As far as I know, Fortran does not have this feature.

-- glen

Arjen Markus

unread,
Jan 4, 2013, 8:17:54 AM1/4/13
to
On Friday, January 4, 2013 1:32:29 PM UTC+1, glen herrmannsfeldt wrote:
...
It is usual to
import java.io.*;
import java.util.*;
which allows using the standard Java packages without the extra qualification that would otherwise be needed. As far as I know, Fortran does not have this feature.

-- glen

No, Fortran allows only one level of qualification. With some care you
can use libraries to isolate modules with the same name from each other,
something along these lines:

module library_a
use module_with_common_name ! Version 1
private

public :: (all those items you want to pass on and are not contained in
module_with_common_name. That module is therefore not needed
by the user of library A)
end module

In a different directory (so that the .mod files are isolated when
compiling):

module library_b
use module_with_common_name ! Version 2
private

public :: (all those items you want to pass on and are not contained in
module_with_common_name. That module is therefore not needed
by the user of library B)
end module

But it remains tricky - if you would need this module with the common
name anyway, which version do you get? You would have to be very careful
with the compiler options to set the right paths.

The linker might still interfer: the entities in the two modules may turn
out to be visible and have the same names.

Regards,

Arjen

\"Vladimír Fuka <"name.surnameat

unread,
Jan 4, 2013, 8:38:05 AM1/4/13
to
Thanks to all. To have some common prefix to the modules used in the
library looks like the best solution.

Vladimir

Richard Maine

unread,
Jan 4, 2013, 11:47:52 AM1/4/13
to
Arjen Markus <arjen.m...@gmail.com> wrote:

> No, Fortran allows only one level of qualification. With some care you
> can use libraries to isolate modules with the same name from each other,

Well, no, Fortran does not allow you to do that. Particular Fortran
compilers might happen to be implemented in such a way that you can pull
such a hack, but that's an implementation artifact of particular
compilers rather than a feature of the language Fortran.

I'm reasonably confident that you understand this, but it didn't come
over explicitly in the words posted, so I thought I'd add the
clarification for the sake of other readers.

Tobias gave the relevant quotes from the standard.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
0 new messages