Tom Gall <tom.g...@linaro.org> wrote: > For shared libs one can define and use something like: > > void __attribute__ ((constructor)) my_init(void); > void __attribute__ ((destructor)) my_fini(void); > > Which of course allows your lib to run code just after the library is > loaded and just before the library is going to be unloaded.
> Unfortunately this doesn't work when people link in the .a from your > lib. Irrespectively of whether it is a good idea to design your library such as to require constructor/destructor routines (:-)) these attributes should work just fine for code that is statically linked. In those cases, the constructor is called early during process startup, and the destructor is called during process exit. So I'm not quite sure why you say this "doesn't work". Absent further details, I can speculate that you might have been running into problems relating to either: - missing object references When linking against a shared library, that whole library gets loaded as a unit, and will always have all its constructors. When linking against a static library, only such object files that are actually (directly or indirectly) referenced by the caller will get pulled into the final executable. If your constructor/destructor routines happen to reside in objects that are not otherwise references, they will simply not be present in the executable and thus not called either. This type of problems can be fixed by keeping constructors/destructors in object files next to routines that rely on them. For example, if you need a constructor to set up a data structure before it can be used, keep the constructor in the same file that provides the main accessor routines to that data structure, such that every user of the data structure must always pull in that object -- and hence the constructor. - initialization order issues The constructors will be called during early startup, which might not be the proper place for whatever they're trying to do (e.g. they might call some other library which itself wasn't initialized yet ...). This is really the same type of problem you also have with shared libraries that are loaded at startup (i.e. not via dlopen), but the details of the constructor call sequence might change in the static case. Does either of those explain the problems you were seeing? Otherwise, if you have more details of what exactly you tried and what went wrong, I'd be happy to have a look ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
