g++ linking issue

[Dennis Handly · Accepted solution]

>Link command and output copied and saved in attachment.

I guess I should have looked more closely at your original message. g++ is broken in that it is treating functions (code) as data:
snmpGet.o: OctetStr::valid() constis DATA UNSAT
../src/.libs/libsnmp++.sl: OctetStr::valid() constis DATA UNSAT
../src/.libs/libsnmp++.sl: OctetStr::valid() constis CODE UNSAT

(I'm not sure why the missing space between the "const" and "is"?)

Can you gzip and attach snmpGet.o and snmpGet.s.
Have you tried going to a newer g++?

[Jens Rehsack]

> >Link command and output copied and saved in attachment.

> I guess I should have looked more closely at your original message. g++ is broken in that it is treating functions (code) as data:
> snmpGet.o: OctetStr::valid() constis DATA UNSAT
> ../src/.libs/libsnmp++.sl: OctetStr::valid() constis DATA UNSAT
> ../src/.libs/libsnmp++.sl: OctetStr::valid() constis CODE UNSAT

I wondered about this, too - but I often seen c++ compilers doing black magic (for my limited knowledge about object files and linking scripts). That's why I do not try to guess when I wonder ...

H.Merijn Brand warned me using g++ 4.2.3 when I asked him personally using original compiler log. I wonder why the bug occurs on hppa only - neither ia64 nor powerpc nor sparc nor x86.

I think I will ask in the development team to update all installed g++ 4.2.n installations, before it happens on other platforms, too.

> (I'm not sure why the missing space between the "const" and "is"?)

me2 ;)
No, this time it's really the result from the executed command by output redirection, no copy'n'waste again :)

> Can you gzip and attach snmpGet.o and snmpGet.s.

Latter needs to be created, but sure.
snmpGet.o.gz is attached.

> Have you tried going to a newer g++?

No, the HP-UX development machine admins arrive back from holiday in 2 days, I will show them this thread and cry "update that! now!" :)

[Dennis Handly]

>I wonder why the bug occurs on PA-RISC only - neither ia64

See the warning messages above. The PA32 linker separates code and data symbol spaces but the ELF linker doesn't, so it doesn't matter.

>snmpGet.o.gz is attached.

It shows the bad type problem:
$ odump -sym 362925.o | fgrep valid
00000000 00000000 Data Unsat 0 .......... 3 00000 _ZNK8OctetStr5validEv

I'm not sure if it also got inlined? I guess not:
$ odump -fix -verb 1 362925.o | fgrep valid
945 16 00000dc8 3167 pc-rel call(rbits=10000, (sym=_ZNK8OctetStr5validEv)
**** sym=_ZNK8OctetStr5validEv is not of type code ****
969 16 00000e28 3167 pc-rel call(rbits=10000, (sym=_ZNK8OctetStr5validEv)
**** sym=_ZNK8OctetStr5validEv is not of type code ****

So:
1) It doesn't get inlined
2) It has the wrong symbol type

[H.Merijn Brand (procura]

If a seperate gcc install is an option, I'd suggest also trying with gcc-3.4.6
I really never got gcc-4 on HP-UX to work reliable (e.g. the perl test suite doesn't pass when compiled with gcc-4).

# cd /tmp
# wget http://mirrors.develooper.com/hpux/gcc-3.4.6-11.11.sd.bz
# bzip2 -d gcc-3.4.6-11.11.sd.bz
# swinstall -s /tmp/gcc-3.4.6-11.11.sd \*

Will install gcc-3.4.6 in /usr/local/pa20_32 and /usr/local/pa20_64

Enjoy, Have FUN! H.Merijn

[Jens Rehsack]

We gave gcc-3.4 a shot, thanks again for clarification. The depot you referred didn't contain headers for std - neither in 32-bit version nor 64-bit, so we finally used the 3.4.3 from http://hpacxx.external.hp.com/gcc (3.4.3, because we found an HP-UX 11.11 machine which has 3.4.3 and it works fine there).

Thanks to you both,
Jens