RE: RE: NM6.1 on Apple-OSX using g95 compiler
Adrian,
The only thing that you can do (other than ignore the warnings) is switch to
a compiler that handles the sizes more appropriately. I don't believe
gfortran or Intel will give these warnings (this is two versions back and I
no longer have gfortran or Intel compile versions on my Mac). You could
also sit down with the source code, do some internet research and figure out
how to make all variables match but I don't think you want to go that route.
:) There are relatively few Mac NONMEM users out there, but, perhaps one
has dealt with it. I just chose to ignore it since my tests showed no
difference in results (in a limited sample of runs).
Bill
_____
Quoted reply history
From: Dunne, Adrian [PRDBE Extern] [mailto:[email protected]]
Sent: Wednesday, December 02, 2009 12:50 PM
To: Bill Bachman
Cc: [email protected]; Nandy, Partha [PRDUS]
Subject: RE: [NMusers] RE: [NMusers] NM6.1 on Apple-OSX using g95 compiler
Bill,
Many thanks for your reply.
I have not personally checked the results for CONTROL5 but my understanding
is that they were checked and found to be OK.
I realize that these messages are not errors but are warnings - however,
from (very painful) past experiences I know that these warnings should be
taken seriously because all kinds of peculiar things can happen when the
common storage is not handled correctly!!
It seems to me that getting 'correct' results for CONTROL5 does not
necessarily imply that these warnings can be ignored for all NONMEM runs.
I do not know enough about the compiler and linker to understand what is
going on here - how much storage is actually being set aside for these
commons and what impact if any does that have on the data to be stored
there??
My hope would be that some of the nmusers who are more knowledgeable than I
am might be able to cast some light on all of this.
Regards,
Adrian
From: [email protected] [mailto:[email protected]] On
Behalf Of Bill Bachman
Sent: 02 December 2009 16:27
To: 'Adrian Dunne'; [email protected]
Subject: [NMusers] RE: [NMusers] NM6.1 on Apple-OSX using g95 compiler
Adriane,
Those are not errors, they are just warnings. I get similar (but not
identical) warnings on a system with nm6.2 and g95 (0.92!) with successful
runs for CONTROL5. Do you get appropriate result files?
Bill
_____
From: [email protected] [mailto:[email protected]] On
Behalf Of Adrian Dunne
Sent: Wednesday, December 02, 2009 10:31 AM
To: [email protected]
Subject: [NMusers] NM6.1 on Apple-OSX using g95 compiler
-----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
_____
No viruses found in this outgoing message
Scanned by iolo AntiVirus 1.5.8.3
http://www.iolo.com http://www.iolo.com/iav/iavsmtp
_______________________________________
No viruses found in this outgoing message
Scanned by iolo AntiVirus 1.5.8.3
http://www.iolo.com