Big Namespace Conflicts

Hi all,

I am in the process of stitching two large fortran programs together, but the two programs have a large number of subroutine names in common. These namespace conflicts cause the linker to fail, of course, with lots of messages like

tinker//libtinker.a(sort.o)(.text+0x0): In function `sort_':
: multiple definition of `sort_'
/exports/localmqm-ix86_64-linux/SVNControlled/molpro2006.1/trunk//lib/libmolpro.a(cirs2util3.o)(.text+0x7a30):/exports/localmqm-ix86_64-linux/SVNControlled/molpro2006.1/trunk/src/mrci/cirs2util3.f:1787: first defined here

for when two subroutine names clash, and

/usr/bin/ld: Warning: alignment 16 of symbol `files_' in /exports/localmqm-ix86_64-linux/SVNControlled/molpro2006.1/trunk//lib/libmolpro.a(modules_sapt.o) is smaller than 32 in tinker//libtinker.a(readxyz.o)

for two common blocks conflict.

Does anyone know of some way to prevent these conflicts, without actually going into the source and changing all the names by hand?

One avenue that I am investigating: I know that pgf90 appends underscores to all fortran objects - is there perhaps a compiler flag to change this behavior?

Hi AaronV,

The best course of action would spend the time and rename the functions. You could even use a macro around your subroutine names which prepends a string to your symbol names so that if you needed to change the naming again (ie back to the original names) it would be as easy as changing the macro definition.

If you don’t what to do this, then you could compile the tinker library with “-Msecond_underscore”. However, I wouldn’t recommend this since it would be very difficult to sort out which “sort” your working with and may cause problems in the future.

Another thing your could try is using the linker flag “-Wl,–allow-multiple-definition” which tells the linker to allow multple symbol definition and only use the first one. Of course, this only works if the two conflicting subroutines do the same thing and have the same prototype. If you do need both the tinker version and molpro version then it’s best to rename the functions.

  • Mat

Thanks for your advice, Mat! I ended up going ahead and changing all the tinker subroutine names with a short perl script … it got the job done.

Your suggestion of using a macro sounds like a more maintainable fix than simply editing the files, although I’m not sure exactly what you’re referring to. Are you talking about a preprocessor feature? If one is appending names to subroutines and functions, would it be smart enough to make a continuation line if the append makes a line go over 72 columns? (That was the really irritating part of editing the files with a perl script.)

Hi Aaron,

My though was that if you even needed to revert back to the original names, it would be easier if you had a macro. Something like:

#define TINKER_FUNC(FNAME) TINKER_/**/FNAME
/* #define TINKER_FUNC(FNAME) FNAME */

       call TINKER_FUNC(foo)(10)
       end

       subroutine TINKER_FUNC(foo)(I)
          print *, I
       end subroutine TINKER_FUNC(foo)

To use C style preprocessing with Fortran, either add the “-Mpreprocess” flag or change your extensions to use “F”/“F90” instead of “f”/“f90”.

To work around the 72 column limit, add the “-Mextend” flag. This extends the number columns to 132.

Hope this helps,
Mat