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