I probably know the answer to this already but ...
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. This helps keep out cruft such as the following out of your design:
PleaseCallThisLibraryFunctionFirstOrThereWillBeAnErrorWhichYouWillHitCausingYouToPostToTheMailingListAskingTheSameQuestionThatHasBeenAsked1000sOfTimes();
Yeah .. you know the function. I don't like it either.
Unfortunately this doesn't work when people link in the .a from your lib. Libs like libjpeg-turbo in theory should never ever need to be linked in that fashion but consider the browsers who link to the universe instead of using system shared libs.
If we accept that linking .a's valid use, and we don't want to promote the use of the function that won't be named in the design and use of libraries, then I'd like to think for the good of humanity the toolchain should allow for the use of __attribute__ ((constructor)) and __attribute__ ((destructor)) to continue to work in the static link case.
Maybe this has already been solved, in which case where is that fine manual as I clearly have some reading to do!
Thoughts?
Thanks!
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com