Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Fortran: multiple definition of `date_'

Jon_D_2
New Contributor I
947 Views

When running Makefile, I am getting the error shown below:

/opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64_lin/libifport.a(idate.o): In function `date_':
idate.c:(.text+0x1b0): multiple definition of `date_'

Is there a compile option that will fix this?  It looks to me that I have a function in local_lib that is the same as one in the compiler lib.

Here is the Makefile I am using:

FC=/opt/intel/bin/ifort
SHLIB=/rxe/source/shlib/v21_cp03/v2.1.cp03
OBJS=contempt28_tu.o inp_routines.o ftb_routines.o con_try.o drxe1.o hx1.o spray1.o local_lib.o
FFLAGS=-debug -align dcommons -real-size 64 -warn nouncalled -warn nousage

all: contempt28_tu.o inp_routines.o ftb_routines.o \
 con_try.o drxe1.o hx1.o spray1.o local_lib.o  \
 ${SHLIB}/hpgl_routines.so contempt28

contempt28: $(OBJS) ${SHLIB}/hpgl_routines.so
 $(FC) $(FFLAGS) -o contempt28 $(OBJS) ${SHLIB}/hpgl_routines.so
 
contempt28_tu.o : contempt28_tu.f 
 $(FC) $(FFLAGS) -c contempt28_tu.f 
 
inp_routines.o : inp_routines.f
 $(FC) $(FFLAGS) -c inp_routines.f
 
ftb_routines.o : ftb_routines.f
 $(FC) $(FFLAGS) -c ftb_routines.f

con_try.o: con_try.f
 $(FC) $(FFLAGS) -c con_try.f
 
drxe1.o : drxe1.f
 $(FC) $(FFLAGS) -c drxe1.f
 
hx1.o : hx1.f
 $(FC) $(FFLAGS) -c hx1.f
 
spray1.o : spray1.f
 $(FC) $(FFLAGS) -c spray1.f
 
local_lib.o : local_lib.f
 $(FC) $(FFLAGS) -c local_lib.f

 

Warnings/Error:

/opt/intel/bin/ifort -debug -align dcommons -real-size 64 -warn nouncalled -warn nousage -c drxe1.f
/opt/intel/bin/ifort -debug -align dcommons -real-size 64 -warn nouncalled -warn nousage -c hx1.f
/opt/intel/bin/ifort -debug -align dcommons -real-size 64 -warn nouncalled -warn nousage -c spray1.f
/opt/intel/bin/ifort -debug -align dcommons -real-size 64 -warn nouncalled -warn nousage -c local_lib.f
/opt/intel/bin/ifort -debug -align dcommons -real-size 64 -warn nouncalled -warn nousage -o contempt28 contempt28_tu.o inp_routines.o ftb_routines.o con_try.o drxe1.o hx1.o spray1.o local_lib.o /rxe/source/shlib/v21_cp03/v2.1.cp03/hpgl_routines.so
ld: Warning: size of symbol `contrl_' changed from 120 in contempt28_tu.o to 1292 in hx1.o
/opt/intel/compilers_and_libraries_2017.1.132/linux/compiler/lib/intel64_lin/libifport.a(idate.o): In function `date_':
idate.c:(.text+0x1b0): multiple definition of `date_'
local_lib.o:/rxe/source/contempt28/v21_cp03/v2.1.cp03/local_lib.f:38: first defined here
ld: warning: libifport.so.5, needed by /rxe/source/shlib/v21_cp03/v2.1.cp03/hpgl_routines.so, not found (try using -rpath or -rpath-link)
ld: warning: libifcoremt.so.5, needed by /rxe/source/shlib/v21_cp03/v2.1.cp03/hpgl_routines.so, not found (try using -rpath or -rpath-link)
ld: warning: libimf.so, needed by /rxe/source/shlib/v21_cp03/v2.1.cp03/hpgl_routines.so, not found (try using -rpath or -rpath-link)
ld: warning: libsvml.so, needed by /rxe/source/shlib/v21_cp03/v2.1.cp03/hpgl_routines.so, not found (try using -rpath or -rpath-link)
ld: warning: libintlc.so.5, needed by /rxe/source/shlib/v21_cp03/v2.1.cp03/hpgl_routines.so, not found (try using -rpath or -rpath-link)
make: *** [contempt28] Error 1
 

 

 

0 Kudos
6 Replies
mecej4
Honored Contributor III
947 Views

Unless the duplicated subprogram (date in your example) has identical interfaces and specifications in your code and the library, you should not simply paper over the problem using linker options (such as ignoring multiple defined symbols). The reasonable action is to remove the duplicated symbol from all except one object.

0 Kudos
Jon_D_2
New Contributor I
947 Views

The subroutine 'date' used in the local_lib appears to be a customized routine with an output of only 10 bytes.   If I can't tell the compiler to only use the customized date routine, I'll have to do some rewriting of the code.  I was hoping for a compiling option that would force the compiler to use date from the application and not from the compiler.  

This a legacy f77 code running on UNIX, and I am porting these codes to Linux.   Thanks for your help.

0 Kudos
TimP
Honored Contributor III
947 Views

If you would supply an explicit interface for your date function, there should be no question of the compiler attempting to use its library version.  For example, putting the function in a module and USE interface, or after CONTAINS .

The best you can do under pure F77 is to comply with the frequently ignored requirement to declare your function EXTERNAL as well as data type declarations in each procedure where it is used.

0 Kudos
mecej4
Honored Contributor III
947 Views

This type of name conflict occurs when a library (such as IFPort) is used for pulling routine A, and that library contains routine B, which has a name conflict with a routine in one of the other user-supplied objects. You can see if you can use a renaming clause in the USE IFPORT statement for the problematic name. Another solution is to alter the name from date to, say, my_date in local_lib, which you have the source code for, and in the caller.

0 Kudos
Jon_D_2
New Contributor I
947 Views

These are old old codes I am going through.   f77 really let you get away with questionable code.  I resolved the problem by changing DATE to DATE1 and going through and updating all the calls to the DATE routine.  I haven't run the code yet to see if there is any additional work that needs to be done relative to the DATE routine.  I have at least a 100 warnings so I'm starting down that path.   I know a few I'll be posting either later today, or tomorrow.

Thank for the posts.

0 Kudos
mecej4
Honored Contributor III
947 Views

You need not let the large count of warning messages discourage you. When a compiler runs into a line of code that it is unable to diagnose correctly, it may emit multiple messages for a single source statement with an error.

0 Kudos
Reply