Hi All,
I am suffering below error for NLD with static library on itanium system (O=
S G06.32.01). I used AR -rc to archive the static library but I can see the=
__.SYMDEF when checking the archive components. This file should be the sy=
mbol table and I tried with -s to force updating this table with the latest=
info.
:ar -t ./../bin/PosParseHandler.a
__.SYMDEF
PosParseHandler.o
When executing the make file, NLD told the .a file can't be resolved.
/usr/bin/c89 -D__TANDEM -DAPP_NO_THREADS -DXERCES_NEW_IOSTREAMS -DXERCES_ST=
D_NAM
ESPACE -DXML_USE_INMEM_MESSAGELOADER -DXERCES_HAS_CPP_NAMESPACE -D_XOPEN_SO=
URCE
-D_XOPEN_SOURCE_EXTENDED=3D1 -Wsystype=3Dguardian -g -Wallow_cplusplus_co=
mments -W
Tandem_float -Woptimize=3D2 -WBstatic -Winspect -Wnowarn=3D1506,770,101,734=
,106,161,
203,262,270,495,1255,1682 -Wcplusplus -Wrunnamed -Wextensions -Wversion3 -W=
nld=3D"
-verbose -s -set systype guardian -set floattype tandem_float" /usr/tandem/=
xml/T
0535V50/lib/GuardianTandemPlatformUtils.o ./obj/POSFLE.o \
-o ../bin/POSFLE -L/usr/tandem/xml/T0535V50/lib -lxerces-c_2_4_0 -=
L./..
/bin -lPosParseHandler.a \
NLD - NATIVE MODE LINKER - T6017D45 - 10JUN06
(C)1993 Tandem (C)2006 Hewlett-Packard Development Company, L.P.
NLD's command line was:
/usr/bin/nld -verbose -s -set SYSTYPE GUARDIAN -set FLOATTYPE
TANDEM_FLOAT -o ../bin/POSFLE -elf -set SYSTYPE GUARDIAN -set
HIGHPIN OFF -set HIGHREQUESTOR OFF -set INSPECT ON -set RUNNAMED
ON /usr/lib/crtlmain.o /usr/lib/cppinit3.o -Bstatic /usr/tandem/xml/T0=
535V5
0/lib/GuardianTandemPlatformUtils.o
./obj/POSFLE.o -L/usr/tandem/xml/T0535V50/lib -l xerces-c_2_4_0
-L./../bin -l PosParseHandler.a -Bdynamic -L /G/system/sys03
-lzstlsrl -Bstatic -Bdynamic -obey /usr/lib/libc.obey -Bstatic
NLD: INFORMATIONAL MESSAGE **** [20022]:
The SRL name or archive name specified as 'xerces-c_2_4_0' in a -l,
-lib, or -import flag was resolved to the archive named
'/usr/tandem/xml/T0535V50/lib/libxerces-c_2_4_0.a'.
NLD: ERROR **** [1148]:
NLD is halting due to the following fatal error:
The search to find an archive did not succeed. The archive filename
that initiated the search was 'PosParseHandler.a'. An archive was
required because the -bstatic flag is currently in effect.
Then, I hardcoded the full path after the -l and the execution file can be =
generated. But this object can't be executed due to the unresovled external=
references. The same code can be passed on Tandem system (OS H06.24.00). T=
he library can be archived without the SYMDEF. And the execution object can=
be ran sucessfully. Need your help sincerely!
> FUP PURGEGDATA \P3DEV.$WORK01.ANDY.WRKPOS
> ADD DEFINE =3DWRKPOS, CLASS MAP, FILE \P3DEV.$WORK01.ANDY.WRKPOS
> RUN \P3D.$DATA01.ANDY.POSFLE \P3DEV.$WORK01.ANDY.POSFILE
PID: \P3D.13,149 \P3D.$DATA01.ANDY.POSFLE (ELF)
External References Not Resolved to Any User/System Library:
Prg: \P3D.$DATA01.ANDY.POSFLE -> Initialize__Q2_11xercesc_2_416XMLPl
atformUtilsSFPCcT1PQ2_11xercesc_2_412PanicHandlerPQ2_11xercesc
Prg: \P3D.$DATA01.ANDY.POSFLE -> Terminate__Q2_11xercesc_2_416XMLPla
tformUtilsSFv (PROC)
Prg: \P3D.$DATA01.ANDY.POSFLE -> __T_Q2_11xercesc_2_412XMLException
(DATA)
*ERROR* PROCESS_CREATE_ Error: 63
Regards
|
|
0
|
|
|
|
Reply
|
zbzazy (5)
|
7/24/2012 10:11:12 AM |
|
This is a bit confusing:
You are stating you are running on an Itanium based system. On the other hand your OS release is G06.32.01 which is running on the MIPS-based S-Series.
NLD and S-Series is ok, on Itanium it would be ELD.
So is there a chance you have mixed up MIPS and Itanium code? That would not work.
|
|
0
|
|
|
|
Reply
|
wolfgang.breidbach (563)
|
7/24/2012 2:29:42 PM
|
|
=E5=9C=A8 2012=E5=B9=B47=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8CUTC+=
8=E4=B8=8B=E5=8D=8810=E6=97=B629=E5=88=8642=E7=A7=92=EF=BC=8Cwbreidbach=E5=
=86=99=E9=81=93=EF=BC=9A
> This is a bit confusing:
> You are stating you are running on an Itanium based system. On the other =
hand your OS release is G06.32.01 which is running on the MIPS-based S-Seri=
es.
>=20
> NLD and S-Series is ok, on Itanium it would be ELD.=20
>=20
> So is there a chance you have mixed up MIPS and Itanium code? That would =
not work.
I believe Andy was meanning to say at MIPS system...
Will @Laba
|
|
0
|
|
|
|
Reply
|
cdyjldy (59)
|
7/24/2012 3:22:02 PM
|
|
andy wrote:
> Hi All,
>
> I am suffering below error for NLD with static library on itanium system (OS G06.32.01). I used AR -rc to archive the static library but I can see the __.SYMDEF when checking the archive components. This file should be the symbol table and I tried with -s to force updating this table with the latest info.
> :ar -t ./../bin/PosParseHandler.a
> __.SYMDEF
> PosParseHandler.o
>
> When executing the make file, NLD told the .a file can't be resolved.
>
> /usr/bin/c89 -D__TANDEM -DAPP_NO_THREADS -DXERCES_NEW_IOSTREAMS -DXERCES_STD_NAM
> ESPACE -DXML_USE_INMEM_MESSAGELOADER -DXERCES_HAS_CPP_NAMESPACE -D_XOPEN_SOURCE
> -D_XOPEN_SOURCE_EXTENDED=1 -Wsystype=guardian -g -Wallow_cplusplus_comments -W
> Tandem_float -Woptimize=2 -WBstatic -Winspect -Wnowarn=1506,770,101,734,106,161,
> 203,262,270,495,1255,1682 -Wcplusplus -Wrunnamed -Wextensions -Wversion3 -Wnld="
> -verbose -s -set systype guardian -set floattype tandem_float" /usr/tandem/xml/T
> 0535V50/lib/GuardianTandemPlatformUtils.o ./obj/POSFLE.o \
> -o ../bin/POSFLE -L/usr/tandem/xml/T0535V50/lib -lxerces-c_2_4_0 -L./..
> /bin -lPosParseHandler.a \
>
>
> NLD - NATIVE MODE LINKER - T6017D45 - 10JUN06
> (C)1993 Tandem (C)2006 Hewlett-Packard Development Company, L.P.
>
> NLD's command line was:
> /usr/bin/nld -verbose -s -set SYSTYPE GUARDIAN -set FLOATTYPE
> TANDEM_FLOAT -o ../bin/POSFLE -elf -set SYSTYPE GUARDIAN -set
> HIGHPIN OFF -set HIGHREQUESTOR OFF -set INSPECT ON -set RUNNAMED
> ON /usr/lib/crtlmain.o /usr/lib/cppinit3.o -Bstatic /usr/tandem/xml/T0535V5
> 0/lib/GuardianTandemPlatformUtils.o
> ./obj/POSFLE.o -L/usr/tandem/xml/T0535V50/lib -l xerces-c_2_4_0
> -L./../bin -l PosParseHandler.a -Bdynamic -L /G/system/sys03
> -lzstlsrl -Bstatic -Bdynamic -obey /usr/lib/libc.obey -Bstatic
>
> NLD: INFORMATIONAL MESSAGE **** [20022]:
> The SRL name or archive name specified as 'xerces-c_2_4_0' in a -l,
> -lib, or -import flag was resolved to the archive named
> '/usr/tandem/xml/T0535V50/lib/libxerces-c_2_4_0.a'.
>
> NLD: ERROR **** [1148]:
> NLD is halting due to the following fatal error:
> The search to find an archive did not succeed. The archive filename
> that initiated the search was 'PosParseHandler.a'. An archive was
> required because the -bstatic flag is currently in effect.
>
> Then, I hardcoded the full path after the -l and the execution file can be generated. But this object can't be executed due to the unresovled external references. The same code can be passed on Tandem system (OS H06.24.00). The library can be archived without the SYMDEF. And the execution object can be ran sucessfully. Need your help sincerely!
>
>
>>FUP PURGEGDATA \P3DEV.$WORK01.ANDY.WRKPOS
>>ADD DEFINE =WRKPOS, CLASS MAP, FILE \P3DEV.$WORK01.ANDY.WRKPOS
>>RUN \P3D.$DATA01.ANDY.POSFLE \P3DEV.$WORK01.ANDY.POSFILE
>
> PID: \P3D.13,149 \P3D.$DATA01.ANDY.POSFLE (ELF)
> External References Not Resolved to Any User/System Library:
> Prg: \P3D.$DATA01.ANDY.POSFLE -> Initialize__Q2_11xercesc_2_416XMLPl
> atformUtilsSFPCcT1PQ2_11xercesc_2_412PanicHandlerPQ2_11xercesc
> Prg: \P3D.$DATA01.ANDY.POSFLE -> Terminate__Q2_11xercesc_2_416XMLPla
> tformUtilsSFv (PROC)
> Prg: \P3D.$DATA01.ANDY.POSFLE -> __T_Q2_11xercesc_2_412XMLException
> (DATA)
> *ERROR* PROCESS_CREATE_ Error: 63
>
>
> Regards
I might have the explanation for part of your problem. I don't completely understand how it works, but if the name after -l is a simple name with no directories included, nld modifies it before searching, added .a to the end if it is doing static linking, and adding .srl if dynamic linking, and some of the descriptions say it also adds "lib" to the beginning of the name. Then it searches for the modified name. I notice that NLD found libxerces-c_2_4_0.a when you specified -lxerces-c_2_4_0, so the rules seems to work for that one. So when you specified -lPosParseHandler.a, I imagine NLD was looking for libPosParseHandler.a.a (or maybe it is smart enough not to double the .a and look for libPosParseHandler.a). If there is a way to tell it to look for exactly the simple name you specify, without modifying it before searching, I don't know what it is. I'd expect to be able to do that without giving the full path name, but maybe it isn't possible. I don't know.
The usual reason for unresolved externals is that you did not specify a library following the point in the NLD command where the code that references the entry point was included. Sometimes, you have to list a library more than one time in order to resolve everything. I don't know enough about the program you are trying to link to say whether that is the reason for the error you are getting, but since you say the same command creates a program without unresolved externals on an H-series system, it seems that you probably have the libraries listed in the correct order. The other thing that could be wrong is that the library does not contain the external symbols you expect it to contain. Or maybe that __.SYMDEF member of the archive is being created incorrectly. I don't know anything about SYMDEF. The manual says it is supposed to be maintained automatically by NLD, as long as all the object file in the archive are of the same type. If you accidently mixed different typ
es of object files in the case that does not work, that could explain the problem.
I know this doesn't solve your problem, but maybe it gives you some hints that will lead in the right direction.
|
|
0
|
|
|
|
Reply
|
kdick (495)
|
7/24/2012 11:37:17 PM
|
|
On 7=D4=C224=C8=D5, =CF=C2=CE=E710=CA=B129=B7=D6, wbreidbach <wolfgang.brei=
db...@bv-
zahlungssysteme.de> wrote:
> This is a bit confusing:
> You are stating you are running on an Itanium based system. On the other =
hand your OS release is G06.32.01 which is running on the MIPS-based S-Seri=
es.
>
> NLD and S-Series is ok, on Itanium it would be ELD.
>
> So is there a chance you have mixed up MIPS and Itanium code? That would =
not work.
apologize for my misleading. yes, this issue is occuring on the MIPS.
The compiling on Itanium with ELD is ok
|
|
0
|
|
|
|
Reply
|
zbzazy (5)
|
7/25/2012 3:29:32 AM
|
|
On 7=D4=C224=C8=D5, =CF=C2=CE=E710=CA=B129=B7=D6, wbreidbach <wolfgang.brei=
db...@bv-
zahlungssysteme.de> wrote:
> This is a bit confusing:
> You are stating you are running on an Itanium based system. On the other =
hand your OS release is G06.32.01 which is running on the MIPS-based S-Seri=
es.
>
> NLD and S-Series is ok, on Itanium it would be ELD.
>
> So is there a chance you have mixed up MIPS and Itanium code? That would =
not work.
Thanks a lot for your reply! And apologize for my misleading. Yes,
this issue is on MIPS and the compiling on Itanium with ELD is ok.
|
|
0
|
|
|
|
Reply
|
zbzazy (5)
|
7/25/2012 3:31:55 AM
|
|
On 7=D4=C225=C8=D5, =C9=CF=CE=E77=CA=B137=B7=D6, Keith Dick <kd...@acm.org>=
wrote:
> andy wrote:
> > Hi All,
>
> > I am suffering below error for NLD with static library on itanium syste=
m (OS G06.32.01). I used AR -rc to archive the static library but I can see=
the __.SYMDEF when checking the archive components. This file should be th=
e symbol table and I tried with -s to force updating this table with the la=
test info.
> > :ar -t ./../bin/PosParseHandler.a
> > __.SYMDEF
> > PosParseHandler.o
>
> > When executing the make file, NLD told the .a file can't be resolved.
>
> > /usr/bin/c89 -D__TANDEM -DAPP_NO_THREADS -DXERCES_NEW_IOSTREAMS -DXERCE=
S_STD_NAM
> > ESPACE -DXML_USE_INMEM_MESSAGELOADER -DXERCES_HAS_CPP_NAMESPACE -D_XOPE=
N_SOURCE
> > -D_XOPEN_SOURCE_EXTENDED=3D1 -Wsystype=3Dguardian -g -Wallow_cplusplu=
s_comments -W
> > Tandem_float -Woptimize=3D2 -WBstatic -Winspect -Wnowarn=3D1506,770,101=
,734,106,161,
> > 203,262,270,495,1255,1682 -Wcplusplus -Wrunnamed -Wextensions -Wversion=
3 -Wnld=3D"
> > -verbose -s -set systype guardian -set floattype tandem_float" /usr/tan=
dem/xml/T
> > 0535V50/lib/GuardianTandemPlatformUtils.o ./obj/POSFLE.o \
> > -o ../bin/POSFLE -L/usr/tandem/xml/T0535V50/lib -lxerces-c_2_4=
_0 -L./..
> > /bin -lPosParseHandler.a \
>
> > NLD - NATIVE MODE LINKER - T6017D45 - 10JUN06
> > (C)1993 Tandem (C)2006 Hewlett-Packard Development Company, L.P.
>
> > NLD's command line was:
> > /usr/bin/nld -verbose -s -set SYSTYPE GUARDIAN -set FLOATTYPE
> > TANDEM_FLOAT -o ../bin/POSFLE -elf -set SYSTYPE GUARDIAN -set
> > HIGHPIN OFF -set HIGHREQUESTOR OFF -set INSPECT ON -set RUNNAMED
> > ON /usr/lib/crtlmain.o /usr/lib/cppinit3.o -Bstatic /usr/tandem/xm=
l/T0535V5
> > 0/lib/GuardianTandemPlatformUtils.o
> > ./obj/POSFLE.o -L/usr/tandem/xml/T0535V50/lib -l xerces-c_2_4_0
> > -L./../bin -l PosParseHandler.a -Bdynamic -L /G/system/sys03
> > -lzstlsrl -Bstatic -Bdynamic -obey /usr/lib/libc.obey -Bstatic
>
> > NLD: INFORMATIONAL MESSAGE **** [20022]:
> > The SRL name or archive name specified as 'xerces-c_2_4_0' in a -l=
,
> > -lib, or -import flag was resolved to the archive named
> > '/usr/tandem/xml/T0535V50/lib/libxerces-c_2_4_0.a'.
>
> > NLD: ERROR **** [1148]:
> > NLD is halting due to the following fatal error:
> > The search to find an archive did not succeed. The archive filena=
me
> > that initiated the search was 'PosParseHandler.a'. An archive was
> > required because the -bstatic flag is currently in effect.
>
> > Then, I hardcoded the full path after the -l and the execution file can=
be generated. But this object can't be executed due to the unresovled exte=
rnal references. The same code can be passed on Tandem system (OS H06.24.00=
). The library can be archived without the SYMDEF. And the execution object=
can be ran sucessfully. Need your help sincerely!
>
> >>FUP PURGEGDATA \P3DEV.$WORK01.ANDY.WRKPOS
> >>ADD DEFINE =3DWRKPOS, CLASS MAP, FILE \P3DEV.$WORK01.ANDY.WRKPOS
> >>RUN \P3D.$DATA01.ANDY.POSFLE \P3DEV.$WORK01.ANDY.POSFILE
>
> > PID: \P3D.13,149 \P3D.$DATA01.ANDY.POSFLE (ELF)
> > External References Not Resolved to Any User/System Library:
> > Prg: \P3D.$DATA01.ANDY.POSFLE -> Initialize__Q2_11xercesc_2_416XMLPl
> > atformUtilsSFPCcT1PQ2_11xercesc_2_412PanicHandlerPQ2_11xercesc
> > Prg: \P3D.$DATA01.ANDY.POSFLE -> Terminate__Q2_11xercesc_2_416XMLPla
> > tformUtilsSFv (PROC)
> > Prg: \P3D.$DATA01.ANDY.POSFLE -> __T_Q2_11xercesc_2_412XMLException
> > (DATA)
> > *ERROR* PROCESS_CREATE_ Error: 63
>
> > Regards
>
> I might have the explanation for part of your problem. I don't completel=
y understand how it works, but if the name after -l is a simple name with n=
o directories included, nld modifies it before searching, added .a to the e=
nd if it is doing static linking, and adding .srl if dynamic linking, and s=
ome of the descriptions say it also adds "lib" to the beginning of the name=
.. Then it searches for the modified name. I notice that NLD found libxerce=
s-c_2_4_0.a when you specified -lxerces-c_2_4_0, so the rules seems to work=
for that one. So when you specified -lPosParseHandler.a, I imagine NLD wa=
s looking for libPosParseHandler.a.a (or maybe it is smart enough not to do=
uble the .a and look for libPosParseHandler.a). If there is a way to tell =
it to look for exactly the simple name you specify, without modifying it be=
fore searching, I don't know what it is. I'd expect to be able to do that =
without giving the full path name, but maybe it isn't possible. I don't kn=
ow.
>
> The usual reason for unresolved externals is that you did not specify a l=
ibrary following the point in the NLD command where the code that reference=
s the entry point was included. Sometimes, you have to list a library more=
than one time in order to resolve everything. I don't know enough about t=
he program you are trying to link to say whether that is the reason for the=
error you are getting, but since you say the same command creates a progra=
m without unresolved externals on an H-series system, it seems that you pro=
bably have the libraries listed in the correct order. The other thing that=
could be wrong is that the library does not contain the external symbols y=
ou expect it to contain. Or maybe that __.SYMDEF member of the archive is =
being created incorrectly. I don't know anything about SYMDEF. The manual=
says it is supposed to be maintained automatically by NLD, as long as all =
the object file in the archive are of the same type. If you accidently mix=
ed different typ
> es of object files in the case that does not work, that could explain the=
problem.
>
> I know this doesn't solve your problem, but maybe it gives you some hints=
that will lead in the right direction.- =D2=FE=B2=D8=B1=BB=D2=FD=D3=C3=CE=
=C4=D7=D6 -
>
> - =CF=D4=CA=BE=D2=FD=D3=C3=B5=C4=CE=C4=D7=D6 -
Thanks a lot for your reply, Dick! I tried with your suggested for
renaming the library with prefix "lib". It works during compiling. But
still occurring the unresolved external reference during running. I
will have a try to compare with the parameter sequence of the normal
one on Itanium. Anyway, you inspired me with a new direction and
sincerely thanks to you.
|
|
0
|
|
|
|
Reply
|
zbzazy (5)
|
7/25/2012 3:37:07 AM
|
|
andy wrote:
> On 7��25��, ����7ʱ37��, Keith Dick <kd...@acm.org> wrote:
>
>>andy wrote:
>>
>>>Hi All,
>>
>>>I am suffering below error for NLD with static library on itanium system (OS G06.32.01). I used AR -rc to archive the static library but I can see the __.SYMDEF when checking the archive components. This file should be the symbol table and I tried with -s to force updating this table with the latest info.
>>>:ar -t ./../bin/PosParseHandler.a
>>>__.SYMDEF
>>>PosParseHandler.o
>>
>>>When executing the make file, NLD told the .a file can't be resolved.
>>
>>>/usr/bin/c89 -D__TANDEM -DAPP_NO_THREADS -DXERCES_NEW_IOSTREAMS -DXERCES_STD_NAM
>>>ESPACE -DXML_USE_INMEM_MESSAGELOADER -DXERCES_HAS_CPP_NAMESPACE -D_XOPEN_SOURCE
>>>-D_XOPEN_SOURCE_EXTENDED=1 -Wsystype=guardian -g -Wallow_cplusplus_comments -W
>>>Tandem_float -Woptimize=2 -WBstatic -Winspect -Wnowarn=1506,770,101,734,106,161,
>>>203,262,270,495,1255,1682 -Wcplusplus -Wrunnamed -Wextensions -Wversion3 -Wnld="
>>>-verbose -s -set systype guardian -set floattype tandem_float" /usr/tandem/xml/T
>>>0535V50/lib/GuardianTandemPlatformUtils.o ./obj/POSFLE.o \
>>> -o ../bin/POSFLE -L/usr/tandem/xml/T0535V50/lib -lxerces-c_2_4_0 -L./..
>>>/bin -lPosParseHandler.a \
>>
>>>NLD - NATIVE MODE LINKER - T6017D45 - 10JUN06
>>>(C)1993 Tandem (C)2006 Hewlett-Packard Development Company, L.P.
>>
>>>NLD's command line was:
>>> /usr/bin/nld -verbose -s -set SYSTYPE GUARDIAN -set FLOATTYPE
>>> TANDEM_FLOAT -o ../bin/POSFLE -elf -set SYSTYPE GUARDIAN -set
>>> HIGHPIN OFF -set HIGHREQUESTOR OFF -set INSPECT ON -set RUNNAMED
>>> ON /usr/lib/crtlmain.o /usr/lib/cppinit3.o -Bstatic /usr/tandem/xml/T0535V5
>>>0/lib/GuardianTandemPlatformUtils.o
>>> ./obj/POSFLE.o -L/usr/tandem/xml/T0535V50/lib -l xerces-c_2_4_0
>>> -L./../bin -l PosParseHandler.a -Bdynamic -L /G/system/sys03
>>> -lzstlsrl -Bstatic -Bdynamic -obey /usr/lib/libc.obey -Bstatic
>>
>>>NLD: INFORMATIONAL MESSAGE **** [20022]:
>>> The SRL name or archive name specified as 'xerces-c_2_4_0' in a -l,
>>> -lib, or -import flag was resolved to the archive named
>>> '/usr/tandem/xml/T0535V50/lib/libxerces-c_2_4_0.a'.
>>
>>>NLD: ERROR **** [1148]:
>>> NLD is halting due to the following fatal error:
>>> The search to find an archive did not succeed. The archive filename
>>> that initiated the search was 'PosParseHandler.a'. An archive was
>>> required because the -bstatic flag is currently in effect.
>>
>>>Then, I hardcoded the full path after the -l and the execution file can be generated. But this object can't be executed due to the unresovled external references. The same code can be passed on Tandem system (OS H06.24.00). The library can be archived without the SYMDEF. And the execution object can be ran sucessfully. Need your help sincerely!
>>
>>>>FUP PURGEGDATA \P3DEV.$WORK01.ANDY.WRKPOS
>>>>ADD DEFINE =WRKPOS, CLASS MAP, FILE \P3DEV.$WORK01.ANDY.WRKPOS
>>>>RUN \P3D.$DATA01.ANDY.POSFLE \P3DEV.$WORK01.ANDY.POSFILE
>>
>>>PID: \P3D.13,149 \P3D.$DATA01.ANDY.POSFLE (ELF)
>>>External References Not Resolved to Any User/System Library:
>>>Prg: \P3D.$DATA01.ANDY.POSFLE -> Initialize__Q2_11xercesc_2_416XMLPl
>>> atformUtilsSFPCcT1PQ2_11xercesc_2_412PanicHandlerPQ2_11xercesc
>>>Prg: \P3D.$DATA01.ANDY.POSFLE -> Terminate__Q2_11xercesc_2_416XMLPla
>>> tformUtilsSFv (PROC)
>>>Prg: \P3D.$DATA01.ANDY.POSFLE -> __T_Q2_11xercesc_2_412XMLException
>>> (DATA)
>>>*ERROR* PROCESS_CREATE_ Error: 63
>>
>>>Regards
>>
>>I might have the explanation for part of your problem. I don't completely understand how it works, but if the name after -l is a simple name with no directories included, nld modifies it before searching, added .a to the end if it is doing static linking, and adding .srl if dynamic linking, and some of the descriptions say it also adds "lib" to the beginning of the name. Then it searches for the modified name. I notice that NLD found libxerces-c_2_4_0.a when you specified -lxerces-c_2_4_0, so the rules seems to work for that one. So when you specified -lPosParseHandler.a, I imagine NLD was looking for libPosParseHandler.a.a (or maybe it is smart enough not to double the .a and look for libPosParseHandler.a). If there is a way to tell it to look for exactly the simple name you specify, without modifying it before searching, I don't know what it is. I'd expect to be able to do that without giving the full path name, but maybe it isn't possible. I don't know.
>>
>>The usual reason for unresolved externals is that you did not specify a library following the point in the NLD command where the code that references the entry point was included. Sometimes, you have to list a library more than one time in order to resolve everything. I don't know enough about the program you are trying to link to say whether that is the reason for the error you are getting, but since you say the same command creates a program without unresolved externals on an H-series system, it seems that you probably have the libraries listed in the correct order. The other thing that could be wrong is that the library does not contain the external symbols you expect it to contain. Or maybe that __.SYMDEF member of the archive is being created incorrectly. I don't know anything about SYMDEF. The manual says it is supposed to be maintained automatically by NLD, as long as all the object file in the archive are of the same type. If you accidently mixed different t
yp
>>es of object files in the case that does not work, that could explain the problem.
>>
>>I know this doesn't solve your problem, but maybe it gives you some hints that will lead in the right direction.- ���ر��������� -
>>
>>- ��ʾ���õ����� -
>
>
> Thanks a lot for your reply, Dick! I tried with your suggested for
> renaming the library with prefix "lib". It works during compiling. But
> still occurring the unresolved external reference during running. I
> will have a try to compare with the parameter sequence of the normal
> one on Itanium. Anyway, you inspired me with a new direction and
> sincerely thanks to you.
You are welcome. I'm glad that my suggestion about the naming of the library archive was helpful.
Something I probably would do to understand the problem better would be to examine the contents of the archive that is causing the problem. I would copy it to a temporary working directory, use the -x option of ar to extract the contents, use noft to see whether the object file actually defines the external symbols that you intended it to define, and use a hex file editor to look at the contents of __.SYMDEF to be sure it properly reflects all the externals defined by the object file. If the -x option does not extract __.SYMDEF from the archive, try the -x option and specifying __.SYMDEF as the filename after the archive name in the command. If that doesn't extract __.SYMDEF, either, try the -p option, specifying the name __.SYMDEF following the archive name, and redirecting stdout to a file. I don't know what the format of __.SYMDEF is, but looking at it with a hex editor should let you tell at least whether the symbols you expect to see there actually are there.
If you find that the symbols are in the .o file, but not in __.SYMDEF, that would seem to be an ar bug. If the symbols are not in the .o file, check how the .o file was created to be sure the .o file was built correctly.
I believe you said that you can get it to work if you don't have __.SYMDEF in the archive. Since ar creates __.SYMDEF automatically when object files are included, how did you try building without __.SYMDEF? Did you use -d to delete __.SYMDEF? If it was as simple as that, maybe deleting __.SYMDEF is the solution to your problem, or at least a good workaround. If it turns out that __.SYMDEF has incorrect contents, please report the problem to HP Customer Support so that the problem can get fixed, eventually.
|
|
0
|
|
|
|
Reply
|
kdick (495)
|
7/25/2012 4:26:16 AM
|
|
|
7 Replies
39 Views
(page loaded in 0.188 seconds)
|