Hi, Rod, Thanks, if I dlopen with RTLD_NOW, or build the libbase.so with -Bdirect, this problem would not happen. I also logged this problem in my blog, http://blogs.sun.com/yongsun/entry/static_constructors_and_symbol_looking
Regards, Rod Evans wrote: > Yong Sun wrote: >> Hi, Rod, >> >> I finally isolated the problem to very simple example C/C++ source >> files, as attached. If you have interests, you could extract the tar >> file, and run gmake. Then you could see, test would core, while test2 >> would succeed. > > Someone from C++ land is going to have to unravel this. > > There are multiple instances of the same symbol in different libraries, > cyclic dependencies, and .init code that jumps all over the place. > > Set LD_DEBUG=.init and we start seeing: > > 04973: 1: calling .init (from sorted order): /usr/lib/libCrun.so.1 > 04973: 1: > 04973: 1: calling .init (dynamically triggered): /usr/lib/libCstd.so.1 > 04973: 1: > 04973: 1: warning: calling /usr/lib/libCrun.so.1 whose init has not > completed > 04973: 1: > 04973: 1: calling .init (dynamically triggered): ./libtest.so > 04973: 1: > 04973: 1: calling .init (dynamically triggered): > /home/rie/dltest/libbase.so > 04973: 1: > 04973: 1: warning: calling ./libtest.so whose init has not completed > 04973: 1: > 04973: 1: warning: calling ./libtest.so whose init has not completed > 04973: 1: > 04973: 1: warning: calling /usr/lib/libCrun.so.1 whose init has not > completed > 04973: 1: > 04973: 1: warning: calling /usr/lib/libCrun.so.1 whose init has not > completed > > Now I can't tell you that these indicate problems or not, as there is no > way to determine whether a reference to another object requires that > object > to have completed its .init for the reference to be valid. Meaning, if > data is updated by a .init, and that data is referenced before the .init > has completed, are you in trouble? > > If you expand a little with init,bindings: > > 04948: 1: calling .init (from sorted order): /usr/lib/libCrun.so.1 > ...... > 04948: 1: binding file=/usr/lib/libCrun.so.1 to > file=/usr/lib/libCstd.so.1: \ > symbol `__SUNW_force_load_of_inits' > 04948: 1: > 04948: 1: calling .init (dynamically triggered): /usr/lib/libCstd.so.1 > > Hmmm, __SUNW_force_load_of_inits - that looks scary. > > 04948: 1: binding file=/usr/lib/libCstd.so.1 to > file=/usr/lib/libCrun.so.1: \ > symbol `__1cG__CrunSregister_exit_code6FpG_v_v_ > 04948: 1: > 04948: 1: warning: calling /usr/lib/libCrun.so.1 whose init has not > completed > > So, you have libCruns .init calling libCstd.so.1, and libCstds .init > calling > libCrun.so.1 > > The scenario continues through your other objects. > > The runtime linker is simply jumping from object to object as directed, > and trying frantically to fire .init's before an object is called. When > cyclic dependencies exist, you can't programaticaly determine a "correct" > order, so the dynamic firing attempts to compensate - and from experience > we know that without this "compensation" a whole mess of applications > would already be falling over. > > I'll stick by my concluding remarks from > > http://blogs.sun.com/rie/entry/init_and_fini_processing_who > > and let's see if someone from C++ can enlighten us some more. >
