| Title: | VAX and Alpha VMS |
| Notice: | This is a new VMSnotes, please read note 2.1 |
| Moderator: | VAXAXP::BERNARDO |
| Created: | Wed Jan 22 1997 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 703 |
| Total number of notes: | 3722 |
Before I escalate this formally via IPMT et. al., has anyone seen a
similar problem or know of a fix that has been issued?
Problem:
LINK loops indefinitely on linking a particular single object module
program. Command sequence is ...
$ CC/DECC NAFION_C ! http://www.stl.dec.com/~cameron/q53471/nafion_c.c
$ LINK NAFION_C ! LINK does not complete
Analysis:
ANALYZE/OBJECT shows no problems with the object module.
No .MAP file is generated, even if LINK/MAP is used.
Suspect LINK coding error or compiler module generation error.
Platforms:
OpenVMS/VAX V6.1, V6.2, V7.0
DEC C V5.2-003, V5.5-002
(John Gillings reports that the object module compiled on OpenVMS/VAX
V6.1 can be linked in VAX V5.5-2H4. Program compiles and links
correctly on OpenVMS/Alpha.)
Other Information:
Compiler Listing
http://www.stl.dec.com/~cameron/q53471/nafion_c.lis
Object Module (OpenVMS/VAX V6.1, DEC C V5.2-003)
http://www.stl.dec.com/~cameron/q53471/nafion_c.obj
I intend to cross-post in the C conference after a suitable interval.
Regards,
James Cameron
Sydney Customer Support Centre, OpenVMS Group
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 658.1 | HTH | AUSS::GARSON | DECcharity Program Office | Wed May 28 1997 23:51 | 30 |
re .0
Never seen it but that sample C file can be cut down lots - which might
help the PB who gets to look at this. I didn't attempt to cut it down
further than the following.
#define Nmax 200 /* = max{Nmax_R,Nmax_X} */
#define Nmax_R 200
#define Nmax_X 20
float Cm[1000],Cs[1000],cs0=5e-4,cm0=1.0,T_exp[100],Cs_exp[100];
float Vsol0,Vmem,Vsample,L,R_out,R_int,delta,xt,st,dR;
float D[Nmax], V[Nmax], bt[Nmax], gt[Nmax];
float cl[Nmax_R][Nmax_X], clh[Nmax_R][Nmax_X], cw[Nmax_R][Nmax_X];
float X1[Nmax_R][Nmax_X],X2[Nmax_R][Nmax_X],X3[Nmax_R][Nmax_X];
float R1[Nmax_R][Nmax_X],R2[Nmax_R][Nmax_X],R3[Nmax_R][Nmax_X];
float XH1[Nmax_R][Nmax_X],XH2[Nmax_R][Nmax_X],XH3[Nmax_R][Nmax_X];
float RH1[Nmax_R][Nmax_X],RH2[Nmax_R][Nmax_X],RH3[Nmax_R][Nmax_X];
float alfaXH[Nmax_R][Nmax_X],alfaRH[Nmax_R][Nmax_X],alfaXH_[Nmax_R][Nmax_X],
alfaRH_[Nmax_R][Nmax_X];
float alfaR,alfaX1,alfaX2,dr=0.0,dx,dt,cr[Nmax_R],Vsol0,Vmem,Vsample;
main()
{
}
(Testing on VAX V6.2)
P.S. Function fi() seems to be doing a "round" in a rather inefficient
way.
| |||||
| 658.2 | use CC/NAME=AS_IS or .. | COMEUP::SIMMONDS | loose canon | Thu May 29 1997 00:27 | 9 |
Re: .0
I can reproduce this with DEC C V5.6 on OpenVMS VAX V7.1 also.. a
little investigation tells me that the linker is having trouble with
the static symbols "dR" and "dr" .. I changed symbol "dR" to "d_R" and
all's well.. hopefully your Customer can use a similar workaround until
someone has a good look.
John.
| |||||
| 658.3 | Workaround Accepted | GIDDAY::CAMERON | And there shall come FORTH (Isaiah 11:1) | Thu May 29 1997 01:08 | 1 |
Thanks. That will help greatly. I shall QAR it. | |||||
| 658.4 | yet another avoidance tactic.. | COMEUP::SIMMONDS | loose canon | Thu May 29 1997 21:32 | 68 |
Another look at the GSD records suggested to me that the bug can also
be avoided by reordering the static definitions for "dR" and "dr",
which should also give a clear clue to the LINKER maintainer.. :)
e.g., change
float Vsol0,Vmem,Vsample,L,R_out=3e-2,R_int=2.5e-2,delta,xt,st,dR;
[...]
float alfaR,alfaX1,alfaX2,dr=0.0,dx,dt,cr[Nmax_R],Vsol0=2.20e-4,Vmem,Vsample=5e-7;
to
float alfaR,alfaX1,alfaX2,dr=0.0,dx,dt,cr[Nmax_R],Vsol0=2.20e-4,Vmem,Vsample=5e-7;
float Vsol0,Vmem,Vsample,L,R_out=3e-2,R_int=2.5e-2,delta,xt,st,dR;
John.
Here are the GSD records (in the original order) which trap the LINKER:
3. GLOBAL SYMBOL DIRECTORY (OBJ$C_GSD), 475 bytes
[...]
28) Global Symbol Specification (GSD$C_SYM)
data type: DSC$K_DTYPE_Z (0)
symbol flags:
(0) GSY$V_WEAK 1
(1) GSY$V_DEF 1
(2) GSY$V_UNI 0
(3) GSY$V_REL 1
(4) GSY$V_COMM 1
psect: 29
value: 0 (%X'00000000')
symbol: "DR"
[...]
9. GLOBAL SYMBOL DIRECTORY (OBJ$C_GSD), 477 bytes
[...]
20) Global Symbol Specification (GSD$C_SYM)
data type: DSC$K_DTYPE_Z (0)
symbol flags:
(0) GSY$V_WEAK 0
(1) GSY$V_DEF 1
(2) GSY$V_UNI 0
(3) GSY$V_REL 1
(4) GSY$V_COMM 0
psect: 29
value: 4 (%X'00000004')
symbol: "DR"
[...]
53. GLOBAL SYMBOL DIRECTORY (OBJ$C_GSD), 482 bytes
[...]
10) Program Section Definition (GSD$C_PSC)
alignment: 4-byte boundary <--
psect 29
attribute flags:
(0) GPS$V_PIC 1
(1) GPS$V_LIB 0
(2) GPS$V_OVR 1
(3) GPS$V_REL 1
(4) GPS$V_GBL 1
(5) GPS$V_SHR 0
(6) GPS$V_EXE 0
(7) GPS$V_RD 1
(8) GPS$V_WRT 1
(9) GPS$V_VEC 0
(10) GPS$V_COM 0
(11) GPS$V_NOMOD 1
allocation: 8 (%X'00000008')
symbol: "DR"
[...]
| |||||
| 658.5 | Logged QAR | GIDDAY::CAMERON | And there shall come FORTH (Isaiah 11:1) | Sun Jun 01 1997 22:27 | 3 |
QAR 01403 on TRIFID logged.
Thanks for your help.
| |||||