g++ linking issue

[Jens Rehsack]

I'm currently setting up an snmp++/agent++ based snmpd for a client who's using gcc/g++ to compile software.

I added some autoconf-stub to snmp++ and compiled it on all taget platforms. All HP-UX 11.x/hppa failed with the same issue. Short log:

g++ -g -O2 -D_REENTRANT -pthread -o .libs/snmpGet snmpGet.o
-L/sysmgmt/opt/openssl/lib -L../src/.libs -lsnmp++
-L/var/bintmp/gcc-4.2.3/gccobj/hppa2.0w-hp-hpux11.23/libstdc++-v3/src
-L/var/bintmp/gcc-4.2.3/gccobj/hppa2.0w-hp-hpux11.23/libstdc++-v3/src/.libs
-L/var/bintmp/gcc-4.2.3/gccobj/./gcc
-L/usr/local/hppa2.0w-hp-hpux11.23/bin -L/usr/local/lib -lstdc++
-L/usr/local/lib/gcc/hppa2.0w-hp-hpux11.23/4.2.3 -L/usr/ccs/lib
-L/opt/langtools/lib -lm -lgcc -lssl -lcrypto -pthread -Wl,+b
-Wl,/var/tmp/build_0.797255175977142/src/.libs:/usr/local/lib
-Wl,+vallcompatwarnings

/usr/ccs/bin/ld: (Warning) Symbol "OctetStr::valid() const" was
defined both in ../src/.libs/libsnmp++.sl and another file to have
incompatible types (such as CODE and DATA). This may not be supported
in future releases.
/usr/ccs/bin/ld: (Warning) Symbol "OctetStr::valid() const" was
defined both in ../src/.libs/libsnmp++.sl and another file to have
incompatible types (such as CODE and DATA). This may not be supported
in future releases.
/usr/ccs/bin/ld: (Warning) Symbol "OctetStr::valid() const" was
defined both in ../src/.libs/libsnmp++.sl and another file to have
incompatible types (such as CODE and DATA). This may not be supported
in future releases.
/usr/ccs/bin/ld: (Warning) Symbol "OctetStr::valid() const" was
defined both in ../src/.libs/libsnmp++.sl and another file to have
incompatible types (such as CODE and DATA). This may not be supported
in future releases.
/usr/ccs/bin/ld: (Warning) Symbol "UdpAddress::clone() const" was
defined both in ../src/.libs/libsnmp++.sl and another file to have
incompatible types (such as CODE and DATA). This may not be supported
in future releases.
/usr/ccs/bin/ld: (Warning) Symbol "UdpAddress::clone() const" was
defined both in ../src/.libs/libsnmp++.sl and another file to have
incompatible types (such as CODE and DATA). This may not be supported
in future releases.
/usr/ccs/bin/ld: (Warning) Symbols named "OctetStr::valid() const" of
incompatible types (such as CODE and DATA) were found in (unknown) and
(unknown). This may not be supported in future releases.
/usr/ccs/bin/ld: (Warning) Symbols named "UdpAddress::clone() const"
of incompatible types (such as CODE and DATA) were found in (unknown)
and (unknown). This may not be supported in future releases.
/usr/ccs/bin/ld: Unsatisfied symbols:
  OctetStr::valid() const(first referenced in snmpGet.o) (data)
collect2: ld returned 1 exit status

HP-UX 11.23 & 11.31 on IA64 work fine, as well as Linux, AIX and Solaris. Full build log is attached.

[Jens Rehsack]

And here's the config.log

[Dennis Handly]

What version of g++ are you using? (It seems to be 4.2.3.)

I'm not sure how you can get this warning:
ld: (Warning) Symbol "OctetStr::valid() const" was defined both in ../src/.libs/libsnmp++.sl and another file to have incompatible types (such as CODE and DATA). This may not be supported in future releases.

Since it has "()" mangled into it, it can only be a function. It seems that your g++ wasn't installed correctly?
Also, it doesn't help that it only says "another file" or "(unknown)".

>ld: Unsatisfied symbols:
à OctetStr::valid() const(first referenced in snmpGet.o) (data)

Where should this be defined? You know it was called from snmpGet.o.
(Was that non-ascii char at the beginning really there?)

[Jens Rehsack]

Yes, I'm using g++ 4.2.3.

"OctetStr::valid() const" is defined in a header file as:
class OctetStr ... {
...
bool valid() const { return validity; };
...
};

So I assume, the compiler emits the symbol for this function in each c++ compiled object which includes the

I tried to compile using "-fno-keep-inline-functions", but it doesn't help.

> (Was that non-ascii char at the beginning really there?)
No, it wasn't - some kind of copy'n'waste error.

[Dennis Handly]

>"OctetStr::valid() const" is defined in a header file as:
class OctetStr { bool valid() const { return validity; }

>the compiler emits the symbol for this function in each C++ compiled object which includes the

It should. You could try to preprocess your snmpGet.C source to see if that class looks like what you showed.
If it does, your compiler is broken, if it doesn't, it could be evil macros.

[Jens Rehsack]

The precompiled source looks like expected for class OctetStr (I didn't read the entire source). Since HP-UX is a supported platform of snmp++ (http://www.agentpp.com/snmp_pp3_x/snmp_pp3_x.html) I'm afraid that the remaining reason is a buggy compiler. But http://hpux.connect.org.uk/ doesn't list a newer (other) compiler as gcc-4.2.3, could there be another source where to get such a compiler from?

[Dennis Handly]

>The preprocessed source looks like expected for class OctetStr

Can you gzip and attach the output of -E?

>could there be another source where to get such a compiler from?

You can get 4.4.3 or 4.3.4 from AllianceONE:
http://www.hp.com/go/gcc

[Jens Rehsack]

> >The preprocessed source looks like expected for class OctetStr

> Can you gzip and attach the output of -E?

Sure.

[Dennis Handly]

I have no problems with 4.3.1 on PA. The symbol is defined in the object file.

You could try linking with -Wl,-y_ZNK8OctetStr5validEv to try tracking down that funny linker warning.

[Jens Rehsack]

Link command and output copied and saved in attachment.

[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