- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Itanium C++ ABI: gcc vs aCC
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2009 04:03 AM
тАО09-11-2009 04:03 AM
I'm in situation when program is compiled with the gcc compiler and linked with HPUX ld. And I found an obstacle when using -fuse-cxa-atexit key of gcc (that triggered the support of http://refspecs.freestandards.org/cxxabi-1.83.html#dso-dtor ) and liking then with /usr/ccs/bin/ld.
Actually gcc creates a __dso_handle (as it said in the 3.3.5.3 "C" section) but the linker simply skip it and it stays as undefined after linkage...
Here is a log of build:
-bash-3.00$ gmake GCC_VERSION=4.3.1 distclean all
rm -f *.o
rm -f libproxy.so.gcc-4.3.1
rm -f libproxy-tiny.so.gcc-4.3.1
rm -f main_app.gcc-4.3.1
/opt/hp-gcc-4.3.1/bin/g++ -c -ggdb -mlp64 -fPIC -pthread -fuse-cxa-atexit main_app.cpp -o main_app.o
/opt/hp-gcc-4.3.1/bin/g++ -v -ggdb -mlp64 -fPIC -pthread -fuse-cxa-atexit -lCsup -Wl,+DSitanium main_app.o -o main_app.gcc-4.3.1
Using built-in specs.
Target: ia64-hp-hpux11.23
Configured with: /tmp/gcc-4.3.1.tar.gz/gcc-4.3.1/configure --host=ia64-hp-hpux11.23 --target=ia64-hp-hpux11.23 --build=ia64-hp-hpux11.23 --prefix=/opt/hp-gcc-4.3.1 --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-languages=c,c++ --with-gmp=/proj/opensrc/be/ia64-hp-hpux11.23 --with-mpfr=/proj/opensrc/be/ia64-hp-hpux11.23
Thread model: posix
gcc version 4.3.1 (GCC)
COMPILER_PATH=/opt/hp-gcc-4.3.1/libexec/gcc/ia64-hp-hpux11.23/4.3.1/:/opt/hp-gcc-4.3.1/libexec/gcc/ia64-hp-hpux11.23/4.3.1/:/opt/hp-gcc-4.3.1/libexec/gcc/ia64-hp-hpux11.23/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../../../ia64-hp-hpux11.23/bin/:/usr/ccs/bin/
LIBRARY_PATH=/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/hpux64/:/usr/ccs/lib/hpux64/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../../hpux64/:/lib/hpux64/:/usr/lib/hpux64/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/:/usr/ccs/lib/:/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-ggdb' '-mlp64' '-fPIC' '-pthread' '-fuse-cxa-atexit' '-o' 'main_app.gcc-4.3.1' '-shared-libgcc'
/opt/hp-gcc-4.3.1/libexec/gcc/ia64-hp-hpux11.23/4.3.1/collect2 -z +Accept TypeMismatch -u main -o main_app.gcc-4.3.1 /usr/lib/hpux64/unix98.o -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/hpux64 -L/usr/ccs/lib/hpux64 -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../../hpux64 -L/lib/hpux64 -L/usr/lib/hpux64 -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1 -L/usr/ccs/lib -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../.. -lCsup +DSitanium main_app.o -lstdc++ -lm -lgcc_s -lunwind -lgcc -lpthread -lc -lgcc_s -lunwind -lgcc
ld: Unsatisfied symbol "__dso_handle" in file main_app.o
1 errors.
collect2: ld returned 1 exit status
gmake: *** [main_app.gcc-4.3.1] Error 1
Symbols from main_app.o:
[Index] Value Size Type Bind O Shndx Name
[0] | 0| 0|NOTYP|LOCAL|0| UNDEF|
[10] | 0| 0|SECT |LOCAL|0|.IA_64.unwind|
[9] | 0| 0|SECT |LOCAL|0|.IA_64.unwind_info|
[13] | 0| 0|SECT |LOCAL|0| .rodata|
[14] | 0| 0|SECT |LOCAL|0| .sbss|
[6] | 0| 0|SECT |LOCAL|0|.debug_line|
[5] | 0| 0|SECT |LOCAL|0|.debug_info|
[15] | 0| 0|SECT |LOCAL|0|.debug_loc|
[17] | 0| 0|SECT |LOCAL|0|.debug_aranges|
[18] | 0| 0|SECT |LOCAL|0|.debug_str|
[19] | 0| 0|SECT |LOCAL|0|.comment|
[12] | 0| 0|SECT |LOCAL|0|.init_array|
[16] | 0| 0|SECT |LOCAL|0|.debug_pubnames|
[1] | 0| 0|SECT |LOCAL|0| .text|
[3] | 0| 0|SECT |LOCAL|0| .bss|
[4] | 0| 0|SECT |LOCAL|0|.debug_abbrev|
[2] | 0| 0|SECT |LOCAL|0| .data|
[11] | 240| 96|FUNC |LOCAL|0| .text|_GLOBAL__I_main_app.cpp
[7] | 0| 240|FUNC |LOCAL|0| .text|_Z41__static_initialization_and_destruction_0ii
[28] | 0| 0|FUNC |GLOB |0| UNDEF|_ZNSolsEPFRSoS_E
[20] | 0| 0|FUNC |GLOB |0| UNDEF|_ZNSt8ios_base4InitC1Ev
[21] | 0| 0|FUNC |GLOB |0| UNDEF|_ZNSt8ios_base4InitD1Ev
[29] | 0| 0|NOTYP|GLOB |0| UNDEF|_ZSt4clog
[25] | 0| 0|NOTYP|GLOB |0| UNDEF|_ZSt4cout
[27] | 0| 0|FUNC |GLOB |0| UNDEF|_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
[8] | 0| 1|OBJT |LOCAL|0| .sbss|_ZStL8__ioinit
[26] | 0| 0|FUNC |GLOB |0| UNDEF|_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
[23] | 0| 0|FUNC |GLOB |0| UNDEF|__cxa_atexit
[22] | 0| 0|NOTYP|GLOB |0| UNDEF|__dso_handle
[33] | 0| 0|FUNC |GLOB |0| UNDEF|dlclose
[31] | 0| 0|FUNC |GLOB |0| UNDEF|dlerror
[30] | 0| 0|FUNC |GLOB |0| UNDEF|dlopen
[32] | 0| 0|FUNC |GLOB |0| UNDEF|dlsym
[24] | 336| 1280|FUNC |GLOB |0| .text|main
And if I compile and link with aCC -- it will do the work for Itanium C++ ABI support silently.. but I can't compile the code I have with aCC..
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2009 04:37 AM
тАО09-11-2009 04:37 AM
Re: Itanium C++ ABI: gcc vs aCC
You can't link C++ directly with ld, you must use the driver.
Unfortunately you can't mix and match aC++ with g++, you can't use -lCsup.
Your g++ compiler is broken if it doesn't generate __dso_handle automatically.
>but I can't compile the code I have with aCC
Why not?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2009 04:55 AM
тАО09-11-2009 04:55 AM
Re: Itanium C++ ABI: gcc vs aCC
>You can't link C++ directly with ld, you must >use the driver.
Yes the collect2 actually is called thru g++, which was configured as such:
Target: ia64-hp-hpux11.23
Configured with: /tmp/gcc-4.3.1.tar.gz/gcc-4.3.1/configure --host=ia64-hp-hpux11.23 --target=ia64-hp-hpux11.23 --build=ia64-hp-hpux11.23 --prefix=/opt/hp-gcc-4.3.1 --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-languages=c,c++ --with-gmp=/proj/opensrc/be/ia64-hp-hpux11.23 --with-mpfr=/proj/opensrc/be/ia64-hp-hpux11.23
Thread model: posix
gcc version 4.3.1 (GCC)
>Unfortunately you can't mix and match aC++ >with g++, you can't use -lCsup.
Why can't? I've linked it for __cxa_atexit and others..
>Your g++ compiler is broken if it doesn't >generate __dso_handle automatically.
That is the point: g++ _do_ generate an undefined symbol on compile time leaving it for linker to fill. And I suppose that GNU linker will fill it, but aC++-one seems to work with it in another way... Actually no __dso_handle symbol I saw after compile and after link by aCC..
>>but I can't compile the code I have with aCC
>Why not?
Cause it's kind of big enterprise solution consisting of many modules and it's multiplatform. So to keep porting time small we use gcc but not native compilers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2009 05:10 AM
тАО09-11-2009 05:10 AM
SolutionBecause aC++ and g++ are binary incompatible.
And g++ should have their own __cxa_atexit.
>g++ _do_ generate an undefined symbol on compile time leaving it for linker to fill.
No, it is the job of g++ to generate that symbol, not HP-UX's ld.
Using HP's 4.2.1, I don't see any references to __dso_handle, though on linux I see it defined in crtbeginS.o.
>Actually no __dso_handle symbol I saw after compile and after link by aCC.
Yes we cheat and use another symbol. That's another reason we aren't binary compatible at the object level.
>So to keep porting time small we use gcc but not native compilers.
aCC has a -Ag++ option which may help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2009 04:21 PM
тАО09-11-2009 04:21 PM
Re: Itanium C++ ABI: gcc vs aCC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-12-2009 04:29 AM
тАО09-12-2009 04:29 AM
Re: Itanium C++ ABI: gcc vs aCC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-13-2009 10:54 PM
тАО09-13-2009 10:54 PM
Re: Itanium C++ ABI: gcc vs aCC
Thank you alot, you've stopped my frustration in this scope.
P.S. Steve, why it's not supported, it doesn't seems to be a hard one?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-14-2009 12:44 AM
тАО09-14-2009 12:44 AM
Re: Itanium C++ ABI: gcc vs aCC
I assume because g++ expects support in libc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-14-2009 08:35 AM
тАО09-14-2009 08:35 AM
Re: Itanium C++ ABI: gcc vs aCC
It is basically just a question of time and priorities. There may be questions of compatibility with the existing method of implementing static constructors and destructors in GCC and it takes time to understand all the issues involved and to come up with a solution that will work in all cases.
At this point I don't know when (or if) it will get done.