NONMEM Users Network Archive

Hosted by Cognigen

RE: RE: NM6.1 on Apple-OSX using g95 compiler

From: Dunne, Adrian [PRDBE Extern] <ADUNNE1>
Date: Wed, 2 Dec 2009 18:49:48 +0100

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: owner-nmusers
On Behalf Of Bill Bachman
Sent: 02 December 2009 16:27
To: 'Adrian Dunne'; nmusers
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: owner-nmusers
On Behalf Of Adrian Dunne
Sent: Wednesday, December 02, 2009 10:31 AM
To: nmusers
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>


Received on Wed Dec 02 2009 - 12:49:48 EST

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to: nmusers-request@iconplc.com.

Once subscribed, you may contribute to the discussion by emailing: nmusers@globomaxnm.com.