topic Re: g++ linking issue in Operating System - HP-UX

g++ linking issue

Jens Rehsack — Fri, 24 Sep 2010 06:45:15 GMT

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.

Re: g++ linking issue

Jens Rehsack — Fri, 24 Sep 2010 06:47:33 GMT

And here's the config.log

Re: g++ linking issue

Dennis Handly — Fri, 24 Sep 2010 07:03:31 GMT

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?)

Re: g++ linking issue

Jens Rehsack — Fri, 24 Sep 2010 08:04:11 GMT

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.

Re: g++ linking issue

Dennis Handly — Fri, 24 Sep 2010 17:50:37 GMT

>"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.

Re: g++ linking issue

Jens Rehsack — Mon, 04 Oct 2010 10:09:33 GMT

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?

Re: g++ linking issue

Dennis Handly — Mon, 04 Oct 2010 11:35:57 GMT

>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

Re: g++ linking issue

Jens Rehsack — Mon, 04 Oct 2010 12:57:32 GMT

> >The preprocessed source looks like expected for class OctetStr

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

Sure.

Re: g++ linking issue

Dennis Handly — Mon, 04 Oct 2010 21:19:47 GMT

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.

Re: g++ linking issue

Jens Rehsack — Tue, 05 Oct 2010 09:35:16 GMT

Link command and output copied and saved in attachment.

Re: g++ linking issue

Dennis Handly — Tue, 05 Oct 2010 18:19:08 GMT

>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++?

Re: g++ linking issue

Jens Rehsack — Wed, 06 Oct 2010 05:20:40 GMT

> >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!" :)

Re: g++ linking issue

Dennis Handly — Wed, 06 Oct 2010 09:34:59 GMT

>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

Re: g++ linking issue

H.Merijn Brand (procura — Tue, 14 Dec 2010 09:00:49 GMT

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

Re: g++ linking issue

Jens Rehsack — Tue, 14 Dec 2010 14:17:48 GMT

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