Alexandre Julliard writes: > The dll init routine needs to be in the .init section in order to be > called first,
Isn't that what attribute((constructor)) does? It places a call to the routine in the .so's initialization section, whatever that section is, so that the routine gets invoked during dlopen(). As far as I know, it's equivalent to the asm() sections it replaces. For example, see the code emitted by BuildDebugFile() in spec32.c ... > attribute((constructor)) is not good enough. I'm perplexed. What is it that attribute((constructor)) does not do? Perhaps it has a different effect on OBSD than on other systems? How can I test whether it, or whatever asm code I replace it with, is doing the right thing? > Why doesn't it work on OpenBSD? Is the section name different? AFAICT, OpenBSD uses a section named .ctors containing function pointers, rather than a section containing 'call' opcodes. At least, that's what attribute((constructor)) emits, and looking through the dlfcn and C runtime sources I don't see any other initialization hooks being called. There *is* a section named .init, but any code placed there will be linked after the C function __init() in crtbeginS.c, and will not be executed because that C function returns normally. But the only thing that __init() does is invoke the functions pointed to by .ctors, and add a hook to make sure that the .dtors are called. Wim.
