Here is some triky way for this problem, you can put the constructor and destructor to the source file which contain necessary function call in your libraries to enforce the linker to archive your constructor and destructor.
However if this solution is not work for your situation, you can apply the patch in attach for build script to enable the LOCAL_WHOLE_STATIC_LIBRARIES for executable,
After patch you can just add a line in your Android.mk :
LOCAL_WHOLE_STATIC_LIBRARIES += libfoo
The most disadvantage of this way is you should always link libfoo by LOCAL_WHOLE_STATIC_LIBRARIES...and this patch don't send to linaro and aosp yet.
On Mon, Dec 5, 2011 at 1:40 AM, Tom Gall tom.gall@linaro.org wrote:
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
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev