Porting from HP-UX IA64 to HP-UX PA-RISC, encountering some compilation and link problems unsatisfied symbol, duplicate symbol

Recently in some platform transplantation, HP's PA-RISC is a relatively old platform, porting often encounter some strange problems:

1. Without the-aa option, you do not need to use the syntax "using namespace STD;
When LD is used, the. o file without the symbols compiled by-aa cannot be compiled by the. O dependency with-aa.
In case of any problems:
Ld: unsatisfied symbol "dchpmonitor: getcpu (STD: vector Find the cause:
[Abp_dev]/project/abp01/abp_dev/abp_pub/release/lib> nm libprocess_info.a | grep getcpu
[11] | 0 | 0 | objt | Local | 0 | $ ratbl $ getcpu _ 11dchpmonitorfr6vectorxt9hbcpuinfot9allocator _ $ range $
[56] | zero | 240 | func | glob | 0 | . Text | getcpu _ 11dchpmonitorfr6vectorxt9hbcpuinfot9allocator _
[Abp_dev]/project/abp01/abp_dev/abp_pub/release/lib> nm libdeamon_service.a | grep getcpu
[168] | 0 | 0 | func | glob | 0 | UNDEF | getcpu _ 11dchpmonitorfrq2_3std6vectorxt9hbcpuinfotq2_3std9allocatorxt9hbcpuinfo __
Visible in libprocess_info.a Although the getcpu symbol exists, it cannot be completed. After comparison, it is found that libdeamon_service.a contains-AA while libprocess_info.a does not. As a result, the symbols of getcpu after name mangling are different.
Compile with the-aa option:
[Abp_dev]/project/abp01/abp_dev/abp_pub/release/lib> nm libprocess_info.a | grep getcpu
[12] | 0 | 8 | objt | Local | 0 | $ aux_action $ getcpu _ 11dchpmonitorfrq2_3std6vectorxt9hbcpuinfotq2_3std9allocatorxt9hbcpuinfo __
[10] | 0 | 0 | objt | Local | 0 | $ ratbl $ getcpu _ 11dchpmonitorfrq2_3std6vectorxt9hbcpuinfotq2_3std9allocatorxt9hbcpuinfo __$ range $
[66] | 0 | 480 | func | glob | 0 | . Text | getcpu _ 11dchpmonitorfrq2_3std6vectorxt9hbcpuinfotq2_3std9allocatorxt9hbcpuinfo __
If the symbols are the same, the LD can pass and the problem is solved.

Man ACC:
-Aa turns on Newly supported ansi c ++ standard features
Like namespace STD and the new C ++ standard library.
This option also implies-aa. Include paths are
Changed to include_std and libraries are libcsup_v2 and
Libstd_v2.
Note: objects and libraries compiled with-aa are
Binary incompatible with objects and libraries compiled
Without-aa.

 

2. The strange duplicate symbol problem in Ace
Ld: duplicate symbol "ace_ OS: fflush (File *)" In files/project/abp01/abp_dev/abp_pub/release/lib/liblog. A [dclogfilemgrcen. o] And/project/abp01/abp_dev/abp_pub/release/lib/libace. A [libACE_la-OS_NS_stdio.o]
LD, a similar problem, dizzy.
Analysis: Ace_ OS: fflush is a function provided in Ace. It should not exist in liblog. A. Use nm to check whether it exists. :
[Abp_dev]/project/abp01/abp_dev/abp_pub/release/lib> nm liblog. A | grep fflush
[394] | 0 | 0 | func | glob | 0 | UNDEF | fflush
[380] | 0 | 72 | func | glob | 0 | $ Code $ inline $ | fflush _ 6ace_osfp4file
Liblog. A really has fflush _ 6ace_osfp4file. Shouldn't it be of the UNDEF type? View type $ code $ inline $ should be caused by inline.
Carefully checked the ACC help and found + Onoinline The options solve this problem, so they are added and the liblog. A compilation is still the same.
What's going on, Finally, you can see a macro in the compilation options:-d1_ace_inline __ Suddenly realized, just remove it and compile liblog.:
[Abp_dev]/project/abp01/abp_dev/abp_pub/release/lib> nm liblog. A | grep fflush
[463] | 0 | 0 | func | glob | 0 | UNDEF | fflush
[375] | 0 | 0 | func | glob | 0 | UNDEF | fflush _ 6ace_osfp4file
The expected UNDEF has finally appeared and the problem is solved.