Hi, Rod, Thank you so much! Yes, you are right, there is a "dynamically triggered" when calling ".init"s:
$ LD_DEBUG=init,detail,demangle ./test 02473: 1: calling .init (from sorted order): /usr/lib/libscim-1.0.so.8 02473: 1: calling .init (dynamically triggered): /usr/lib/gtk-2.0/immodules/im-scim.so And seems that the "dynamically triggered" is caused by resolving the __null_string_ref_rep symbol: $ LD_DEBUG=init,symbols,bindings,demangle ./test 25357: 1: calling .init (from sorted order): /usr/lib/libscim-1.0.so.8 25357: 1: 25357: 1: symbol=__rwstd::__null_string_ref_rep<unsigned,std::char_traits<unsigned>,std::allocator<unsigned>,__rwstd::__string_ref_rep<std::allocator<unsigned> > >::__null_string_ref_rep(); lookup in file=test [ ELF ] 25357: 1: symbol=__rwstd::__null_string_ref_rep<unsigned,std::char_traits<unsigned>,std::allocator<unsigned>,__rwstd::__string_ref_rep<std::allocator<unsigned> > >::__null_string_ref_rep(); lookup in file=/lib/libc.so.1 [ ELF ] 25357: 1: symbol=__rwstd::__null_string_ref_rep<unsigned,std::char_traits<unsigned>,std::allocator<unsigned>,__rwstd::__string_ref_rep<std::allocator<unsigned> > >::__null_string_ref_rep(); lookup in file=/usr/lib/gtk-2.0/immodules/im-scim.so [ ELF ] 25357: 1: binding file=/usr/lib/libscim-1.0.so.8 to file=/usr/lib/gtk-2.0/immodules/im-scim.so: symbol `__rwstd::__null_string_ref_rep<unsigned,std::char_traits<unsigned>,std::allocator<unsigned>,__rwstd::__string_ref_rep<std::allocator<unsigned> > >::__null_string_ref_rep()' 25357: 1: 25357: 1: calling .init (dynamically triggered): /usr/lib/gtk-2.0/immodules/im-scim.so 25320: 1: calling .init (from sorted order): /usr/lib/libscim-1.0.so.8 25320: 1: calling .init (dynamically triggered): /usr/lib/gtk-2.0/immodules/im-scim.so And from the nm result of libscim-1.0.so, we can tell, the symbol is also available in libscim-1.0.so, $ nm /usr/lib/libscim-1.0.so | c++filt | grep __null_string_ref_rep [2593] | 820544| 84|FUNC |GLOB |0 |14 |__rwstd::__null_string_ref_rep<unsigned,std::char_traits<unsigned>,std::allocator<unsigned>,__rwstd::__string_ref_rep<std::allocator<unsigned> > >::__null_string_ref_rep() So, is the looking up and binding order is incorrect? Regards, Rod Evans wrote: > Yong Sun wrote: > >> [4] scim::__initialize_config(), line 131 in "scim_global_config.cpp" >> [5] scim::scim_global_config_read(key = CLASS, defVal = 5000), line >> 183 in "scim_global_config.cpp" >> [6] scim::scim_get_default_socket_timeout(), line 1214 in >> "scim_socket.cpp" >> [7] scim::PanelClient::PanelClientImpl::PanelClientImpl(this = >> 0x8085318), line 86 in "scim_panel_client.cpp" >> [8] scim::PanelClient::PanelClient(this = 0xfbfe9510), line 566 in >> "scim_panel_client.cpp" >> [9] __SLIP.INIT_I(0xfbfe11e8, 0xfbfc33f9, 0x8046e8c, 0xfbfcd807, >> 0xfeffa7d0, 0xfe660438), at 0xfbfb035f >> [10] __STATIC_CONSTRUCTOR(), line 301 in "gtkimcontextscim.cpp" >> [11] __cplus_fini_at_exit(0xfbf93760, 0xfe660438, 0xfeffa7d0, >> 0xfbc10df8, 0xfefd05dc, 0xfbc10df8), at 0xfbfcd807 >> [12] call_init(0xfbc10df8, 0x3), at 0xfefd380f >> [13] is_dep_init(0xfe660438, 0xfbf80490), at 0xfefd357c >> [14] elf_bndr(0xfbf80490, 0x2d8, 0xfbe6ccbf), at 0xfefde53c >> [15] elf_rtbndr(0x2d8, 0xfbe6ccbf, 0xfbfe9594, 0x0, 0xfbf2f200, >> 0xfbe6cc79), at 0xfefc8c24 >> [16] 0xfbf80490(0xfbf2f200, 0xfbe6cda9, 0x8046fcc, 0xfbf0890b, >> 0xfeffa7d0, 0xfbf80490), at 0xfbf80490 >> [17] __STATIC_CONSTRUCTOR(), line 42 in "string.cc" >> [18] __cplus_fini_at_exit(0xfeffa2d8, 0xfe660438, 0xfeffa7d0, 0xc, >> 0x8047024, 0xfefd7d91), at 0xfbf0890b >> [19] call_init(0xfbc10db0, 0x1), at 0xfefd380f >> [20] load_completion(0xfe660438, 0xfec425b0), at 0xfefd3dfa >> [21] dlmopen_intn(0xfeffa2d8, 0x8066c40, 0xd01, 0xfec425b0, 0x0, 0x0, >> 0x80470d0), at 0xfefd7ff0 >> [22] dlmopen_check(0xfeffa2d8, 0x8066c40, 0xd01, 0xfec425b0, >> 0x80470d0), at 0xfefd80e0 >> [23] _dlopen(0x8066c40, 0x101), at 0xfefd81a1 >> [24] _g_module_open(0x8066c40, 0x1, 0x0), at 0xfc59118a >> [25] g_module_open(0x8065008, 0x0), at 0xfc59175c >> [26] query_module(0x8064308, 0xfee84042), at 0x805137a >> [27] main(0x1, 0x80471f0, 0x80471f8), at 0x8051651 > > Perhaps you have a cyclic dependency. > > This trace shows that ld.so.1 has kicked off a .init [19] as part of the > dlopen [23]. From exercising the __STATIC_CONSTRUCTOR [17], ld.so.1 has > been asked to bind to another function [15], which is presumably to an > object whose init hasn't fired yet. Before the binding is established, > ld.so.1 calls the defining objects .init [12]. > > If you turned on the runtime linkers debugging, I 'd expect you'd see > something like: > > 09086: calling .init (dynamically triggered): ./libXXXX.so.1 > > For a description of the complexities of init/fini processing, see: > > http://blogs.sun.com/rie/entry/init_and_fini_processing_who >
