Removing the -Bsymbolic option has no effect. I created a test prog, that just does just does a:
dlopen(...,RTLD_NOW | RTLD_GLOBAL) and that works fine. Another tid-bit... If I LD_PRELOAD=libCstd.so.1, my crash goes away. Clark -----Original Message----- From: Rod Evans [mailto:[email protected]] Sent: Monday, March 06, 2006 4:21 PM To: Milliken, Clark Cc: tools-linking at opensolaris.org Subject: Re: [tools-linking] shared lib using libCstd under java Clark Milliken wrote: > ef88b09c _init (0, 1, 1c, fab91048, 20000000, 40000000) + 1e0 > ff3c0254 call_init (400000, 80000, ff3ee7c4, fab91118, ffffffff, 0) + 1a8 > ff3c56d4 dlmopen_intn (ff3ee0c4, af450, c01, feef0e78, 0, 0) + 80 > ff3c5818 dlmopen_check (ff3ee0c4, af450, 1, feef0e78, ffbfd8dc, ffbfe098) + 134 > ff3c58d4 dlopen (af450, 1, 0, f681e108, 32793c, 0) + ac The dlopen() call is executing your .init code (running constructors). I guess a simple C++ a.out that dlopen'd your object would fall over in the same manner. > Compile flags (CC):-Dsolaris -features=no%localfor -pta -KPIC -mt > Link (done with CC) flags:-G -z text -dy -B symbolic -Dsolaris -features=no%localfor -pta -KPIC -mt -lCstd -lm ^^^^^^^^^^^ The C++ folks don't like the -Bsymbolic option. It can result in multiple instances of the same symbol being bound to from different objects within the process. The implementation details of many aspects of C++ expect multiple instances of their symbols to be interposed upon - ie. one symbol definition wins. What happens if you remove the -Bsymbolic. Alternative ways of reducing symbol scope in C++ exist, although the C++ documentation used to be rather sparse in such details. Try: http://blogs.sun.com/roller/page/rie?entry=interface_creation_using_the_ compilers -- Rod
