Re: problems with g++, Informix ODBC lib on SunOS
Linking g++ C++ programs with Informix's libodbc.so (a C++-written library) on SunOS caused bus errors before main() due to symbol name clashes between SunOS libC.so and g++ libstdc++. Workarounds discussed included: using Sun CC instead, explicitly dlopen()ing the library with function wrappers, or modifying g++ symbol mangling. No definitive fix was adopted in the thread.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
In article <casper.916181060@nl-usenet.sun.com>, Casper H.S. Dik - Network Security Engineer wrote: >andrew@pimlott.ne.mediaone.net (Andrew Pimlott) writes: > >>Synopsis: Linking with an Informix shared library on SunOS causes a trivial >>C++ program that does not use that library to bus error before main() in >>(seemingly unrelated) C++ initialization code. The problem occurs with >>various versions of g++, but not Sun CC. > >>According to 'info sharedlibrary', the top three calls are in libC.so.5 (a >>SunOS system library), and the other four aren't in shared libraries. > >While this may be a lot of work to check, the most obvious problem could be >that there is some overlap in the names of symbols exported by libC.so.5 and >the g++ libraries. This may cause mismatched calls which woudl explain >your troubles. Of course, now it all makes sense. I didn't realize that the libodbc.so was written in C++, and I was unsure of exactly what libC.so's function was (I assume it is the equivalent of libstdc++ in egcs). After some further hacking and testing, the most promising ideas seem to be: - Use Sun CC. Can someone give me a general idea of how well it handles "interesting" C++? Exceptions, template, STL, the usual suspects. - Get the symbols of libC.so and libstdc++.so not to clash. I'm trying to find out whether g++ has any "customized mangling" features, but I'm worried that this may be a hornet's nest. Thank you, Andrew
Hi Andrew, I am having the exact same problem as you on Solaris 2.5.1 with GCC 2.8.1 but with libnotes instead of libodbc. The frightening part is that the stack in the GDB is also exactly the same as yours. I have not tried to compile with SUN CC but I have tried various versions of GCC and the problem remains same. I could cause a small program: ---------------- #include <std/bastring.h> typedef basic_string <char> string; void main(int argc, char *argv[]) { string a; } ------------ when linked with libnotes to core dump with the exact same stack. It looks like that program is trying to initialize iostream from libC instead of from libstdc++. In article <slrn79pr8t.u2t.andrew@pimlott.ne.mediaone.net>, pimlott@math.harvard.edu wrote: > In article <casper.916181060@nl-usenet.sun.com>, Casper H.S. Dik - Network > Security Engineer wrote: > >andrew@pimlott.ne.mediaone.net (Andrew Pimlott) writes: > > > >>Synopsis: Linking with an Informix shared library on SunOS causes a trivial > >>C++ program that does not use that library to bus error before main() in > >>(seemingly unrelated) C++ initialization code. The problem occurs with > >>various versions of g++, but not Sun CC. > > > >>According to 'info sharedlibrary', the top three calls are in libC.so.5 (a > >>SunOS system library), and the other four aren't in shared libraries. > > > >While this may be a lot of work to check, the most obvious problem could be > >that there is some overlap in the names of symbols exported by libC.so.5 and > >the g++ libraries. This may cause mismatched calls which woudl explain > >your troubles. > > Of course, now it all makes sense. I didn't realize that the libodbc.so was > written in C++, and I was unsure of exactly what libC.so's function was (I > assume it is the equivalent of libstdc++ in egcs). > > After some further hacking and testing, the most promising ideas seem to be: > > - Use Sun CC. Can someone give me a general idea of how well it handles > "interesting" C++? Exceptions, template, STL, the usual suspects. > > - Get the symbols of libC.so and libstdc++.so not to clash. I'm trying to > find out whether g++ has any "customized mangling" features, but I'm > worried that this may be a hornet's nest. > > Thank you, > Andrew > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <77o18n$lvg$1@nnrp1.dejanews.com>, anjali.arora@cai.com wrote: >I am having the exact same problem as you on Solaris 2.5.1 with GCC 2.8.1 but >with libnotes instead of libodbc. The frightening part is that the stack in >the GDB is also exactly the same as yours. I have not tried to compile with >SUN CC but I have tried various versions of GCC and the problem remains same. >I could cause a small program: > >---------------- >#include <std/bastring.h> > >typedef basic_string <char> string; > >void main(int argc, char *argv[]) { string a; } >------------ > >when linked with libnotes to core dump with the exact same stack. Scary! At least it pinpoints the problem. You mentioned that creating a static version of libnotes helped in a test program. Did you create this with a simple "ar rs libnotes.a libnotes.so", or is there more to it? To compare notes, we used a similar trick: Instead of linking to libodbc.so, we dlopen()'d it explicitly, and wrote wrappers for the odbc functions we need that call a function pointer returned by dlsym(). Miraculously, this has worked so far. Probably, this is because libodbc.so does not make much (any?) use of libC.so, so it doesn't miss it. Of course, if libodbc.so actually does call functions it expects to be in libC.so, anything can happen; we're crossing our fingers that our luck holds. The potential solution that appeals to me the most would be to make g++ mangle C++ symbols such that we can link to both libstdc++ and libC without symbol name clash. Technically, this must be possible, but I haven't yet figured out how much hacking it would take. Andrew
Andrew Pimlott wrote: > ... > Of course, now it all makes sense. I didn't realize that the libodbc.so was > written in C++, and I was unsure of exactly what libC.so's function was (I > assume it is the equivalent of libstdc++ in egcs). > > After some further hacking and testing, the most promising ideas seem to be: > > - Use Sun CC. Can someone give me a general idea of how well it handles > "interesting" C++? Exceptions, template, STL, the usual suspects. I use Exception handling and templates in Sun CC 4.2 and I find they work very well (as long as you remember to nuke your Template.DB directory when you rebuild). I find that the same in g++ works very badly (random core dumps and bad stacks like you got). Here's a good one for g++ : void main() { int x=10; } Compile with g++ -g and step over 'int x=10' and print x in gdb. I find most of the time it's not 10. I also find that most class members printed in gdb are wrong as well. I haven't used STL on Solaris because I haven't been able to get it to compile. Does anyone have it for Solaris (I know it's in Workshop 5 but we won't upgrade until it's GA)? Don
In comp.unix.solaris "Clayton, Don (EXCHANGE:CAR:1W13)" <donclay@americasm01.nt.com> wrote: : Andrew Pimlott wrote: :> ... :> Of course, now it all makes sense. I didn't realize that the libodbc.so was :> written in C++, and I was unsure of exactly what libC.so's function was (I :> assume it is the equivalent of libstdc++ in egcs). :> :> After some further hacking and testing, the most promising ideas seem to be: :> :> - Use Sun CC. Can someone give me a general idea of how well it handles :> "interesting" C++? Exceptions, template, STL, the usual suspects. <snip> :I haven't used STL on Solaris because I haven't been able to get it to compile. : Does anyone have it for Solaris (I know it's in Workshop 5 but we won't : upgrade until it's GA)? Avoiding STL all this time? Pop for $50 and get STL from http://www.objectspace.com or get the Standard C++ Library from RogueWave http://www.roguewave.com/products/stdlib/ for $295 - which is what ships with CC 5.0. CC 5.0 isn't going to ship for a good 6 months. And remember, friends don't let friends use Tools.h++.
In comp.databases.informix Clayton, Don (EXCHANGE:CAR:1W13) <donclay@americasm01.nt.com> wrote: > Andrew Pimlott wrote: >> ... >> Of course, now it all makes sense. I didn't realize that the libodbc.so was >> written in C++, and I was unsure of exactly what libC.so's function was (I >> assume it is the equivalent of libstdc++ in egcs). >> >> After some further hacking and testing, the most promising ideas seem to be: >> >> - Use Sun CC. Can someone give me a general idea of how well it handles >> "interesting" C++? Exceptions, template, STL, the usual suspects. > I use Exception handling and templates in Sun CC 4.2 and I find they work > very well (as long as you remember to nuke your Template.DB directory when > you rebuild). I find that the same in g++ works very badly (random core > dumps and bad stacks like you got). Here's a good one for g++ : > void main() > { > int x=10; > } > Compile with g++ -g and step over 'int x=10' and print x in gdb. I find most of > the time it's not 10. I also find that most class members printed in gdb > are wrong as well. Strange, I had 2.8.0 working fine. > I haven't used STL on Solaris because I haven't been able to get it to compile. > Does anyone have it for Solaris (I know it's in Workshop 5 but we won't > upgrade until it's GA)? Actually, I found the Sun C++ rather limited in many of the "interesting C++" features but you can get STLport. This is the SGI STL made compilable by other "lesser" C++ compilers. :) > Don Enjoy, Dan -- Dan Miner dminer@nyx.net | | Doing Programmer/ | | Linux Linux Consultant | "What yonder light Windows 95 breaks?" | since http://www.nyx.net/~dminer/ | "Free software: The New Frontier" | v0.12