aCC linking problem

[Subhendu]

Hi,
I am facing a strange problem while upgrading one application from cfront to aCC. While linking the "ld" process shoots up CPU utilization to 99% and the linking process hangs. Using -v option I am getting the following unsatisfied symbols errors. I've not forgot to add libCSup library.

Searching library /usr/lib/milli.a:
/opt/aCC/lbin/ld: Unsatisfied symbols:
__eh_Cofstream (data)
__ct__7SMPLMSGFPCc_1 (code)
send__7SMPLMGRFPFP7SMPLREQP7SMPLRSP_8CCSTATUSPv (code)
__ct__7SMPLMGRFQ2_8DMQXPORT4MODE_1 (code)
__eh_dummy_catch_table (data)
__eh_dt_count (data)
find_error_desc__7DSAPMIBFl (code)
__ct__6TRACERFv_1 (code)
__ct__8SMPLATTRFPCcT1_1 (code)
show_log_header__F8SEVERITYPCci (code)
__ct__9DSAPUSAGEFv_1 (code)

Can anyone please help me to get rid of this problem. Thanks in advance.
Regards,

Subhendu

[Steven Gillard_2]

A couple of things to check:

- Make sure you're using aCC to perform the link step instead of invoking ld directly

- Make sure *all* your object files and libraries have been compiled with aCC. You cannot mix cfront objects with aCC objects otherwise you will get these types of unsatisfied symbols.

If you haven't seen it already, take a look at the cfront to aCC migration guide at:

http://docs.hp.com/hpux/onlinedocs/dev/aCC/a_03_30/migrate.htm

Regards,
Steve

[Subhendu]

Hi Steve,
We are linking using aCC itself.
We are generating all .o files using aCC,
but are linking with few archive files like DSAP, which we were using for earlier cfront version.
Infact we tried on HPUX11.0 it's going fine. Would there be any issue on the current patch level on HPUX 10.2, what we're using.

I found that, for milli.a we have an older patch
PHSS_15389.PHSS_15389: /usr/lib/milli.a

Would that be a reason?

Thanks in advance. Regards,

Subhendu

[Steven Gillard_2]

Do the DSAP libraries contain C++ classes? If so you will need to get aCC versions of these libraries.

Try using the c++filt utility to 'demangle' the symbol names back into something more meaningful (ie Class::function(arg) style). That may give you some more information on where they come from. If the aCC c++filt command can't demangle the symbols then you can be sure that they're cfront symbols. The fact that they're not being demangled as it is indicates to me that this is the problem.

Regards,
Steve

[Subhendu]

Hi Steve,
We've tried your suggestion of compiling libraries with aCC. Still we are facing problem in linking. This time 'Unsatisfied symbols' are somewhat different.

Searching library /usr/lib/milli.a:
/opt/aCC/lbin/ld: Unsatisfied symbols:
__ct__7SMPLMSGFPCc_1 (code)
send__7SMPLMGRFPFP7SMPLREQP7SMPLRSP_8CCSTATUSPv (code)
__ct__7SMPLMGRFQ2_8DMQXPORT4MODE_1 (code)
find_error_desc__7DSAPMIBFl (code)
__ct__6TRACERFv_1 (code)
reset__9SMPLALISTFv (code)
__ct__8SMPLATTRFPCcT1_1 (code)
show_log_header__F8SEVERITYPCci (code)
__ct__9DSAPUSAGEFv_1 (code)

Do we need to include any more libraries? Is there any patch dependency for milli.a

Thank you in advance
Subhendu

[Steven Gillard_2]

What does the following command output:

$ echo "__ct__7SMPLMSGFPCc_1" | /opt/aCC/bin/c++filt

(I don't have access to a system with aCC on it at the moment so can't do this myself). If you still have the cfront compiler installed, also try the cfront c++filt command:

$ echo "__ct__7SMPLMSGFPCc_1" | /opt/CC/bin/c++filt

This will at least give you better information on where the unsats are coming from.

I doubt the milli.a patch has much to do with this, but you should definitely make sure you are up to date patch wise - particularly the aCC compiler and library patches.

Regards,
Steve

[Subhendu]

Hi,

We got the aCC compatible DSAP Libraries, even now we are facing with the same problem (ie) linking hangs. We were using -v option for linking and to our surprise we noticed in the /var/tmp directory a file has been created of size zero. Also the linking process doesnot throw any errors.

Thanks & Regards
Subhendu B

[Subhendu]

Hi,
Here is one more observation from our side.
We tried the same set of files to compile on HPUX11.00 using aCC. We were able to generate the executable. Following are the versions of HPUX and corresponding aCC. Can anyone help to identify the problem

Not working DETAILS
*******************
HP-UX B.10.20 A 9000/800 845337411 two-user license

aCC: HP ANSI C++ B3910B A.01.15

Working DETAILS
***************
HP-UX B.11.00 A 9000/889 279824341 two-user license

aCC: HP ANSI C++ B3910B A.03.30

Thank you in advance

Subhendu

[Steven Gillard_2]

Good news that the unsats are gone. For the hang all I can suggest is patches - make sure you have the latest ld patch installed (PHSS_21110 for 10.20), and it would be a good idea to get your aCC up to the latest release, which is A.01.27. See the following page for patch and version information:

http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,1743,00.html#10x

Regards,
Steve