This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>>>>> On Wed, 27 Nov 2002 15:09:58 -0800, "H. J. Lu" <hjl@lucon.org> said: HJ> I am not sure how this approach will work. If I get it right, HJ> __libc_do_init_calls and __libc_do_fini_calls are defined in HJ> executables. But they are only available when executables are HJ> linked against with the new glibc. For the existing executables, HJ> there are no __libc_do_init_calls nor __libc_do_fini_calls. That HJ> is why my original solution has Old executables directly pass _init() and _fini() to __libc_start_main, so they'll work normally. Of course, the preinit_array, init_array, and fini_array in such executables won't be executed either, but since this support is new, those binaries presumably don't have such sections. Also, ld.so should take care of executing init_array and fini_array for the shared objects that the executable depends on, so I think everything should be fine. --david
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |