I've seen the same error when working on Boomer. I forget my resolution. Are you using the latest version of g95? Have you tried gfortran?
gfortran http://gcc.gnu.org/wiki/GFortran or g95 http://www.g95.org/downloads.shtml http://hpc.sourceforge.net/ is also useful David Bourne On 02/12/2009, at 9:30 AM, Adrian Dunne wrote: > -----Original Message----- > From: Nandy, Partha [PRDUS] > Sent: 25 November 2009 15:44 > To: nmusers > Subject: NM6.1 on Apple-OSX using g95 compiler > > Dears, > > We are trying to run NM6.1 on Apple-OSX using g95 compiler. After compiling, > when the CONTROL5 test case was executed, we got the following errors. The > error msg was the same when we tried other control files. Thanks to Adrian > (Dunne), he first brought this problem to my attention. We tried the quick > and easy solution of recompiling but that did not solve the problem. > > Error: > > ld: warning for symbol _lcm3_ tentative definition of size 368 from > /Users/Shared/nmvi/nm/nonmem.a(CFILES.o) is is smaller than the real > definition of size 360 from /Users/Shared/nmvi/nm/BLKDAT.o > ld: warning for symbol _cm42_ tentative definition of size 16 from > /Users/Shared/nmvi/nm/nonmem.a(INITL.o) is is smaller than the real > definition of size 8 from /Users/Shared/nmvi/nm/BLKDAT.o > ld: warning for symbol _lcm3_ tentative definition of size 368 from > /Users/Shared/nmvi/nm/nonmem.a(OFILES.o) is is smaller than the real > definition of size 360 from /Users/Shared/nmvi/nm/BLKDAT.o > ld: warning for symbol _cm42_ tentative definition of size 16 from > /Users/Shared/nmvi/nm/nonmem.a(EIGRS1.o) is is smaller than the real > definition of size 8 from /Users/Shared/nmvi/nm/BLKDAT.o > ld: warning for symbol _cm42_ tentative definition of size 16 from > /Users/Shared/nmvi/nm/nonmem.a(EQRT21.o) is is smaller than the real > definition of size 8 from /Users/Shared/nmvi/nm/BLKDAT.o > > > Upon further investigation, Adrian nailed the source of the problem down to > the following: > > The first error message tells us that the common storage area named LCM3 has > size 368 in CFILES.OBJ and size 360 in file BLKDAT.OBJ. He then looked at the > fortran versions of these files (CFILES.for and BLKDAT.for) and found that in > each of them 360 storage locations are set aside for LCM3. > > My question is why there should be a difference between the storage > allocation for the common area LCM3 in the fortran source code and the object > code ( I am assuming that the .for and .obj files do in fact correspond with > each other)? > > Is this anomaly driven by the compiler that created the object code? > > All of the other error messages are similar to the first one and the guess is > that if we sort this one out the others will be sorted similarly. > > Any suggestions from the group will be of great help. > > Best Regards-Partha >
