| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Some libc changes were preventing the initialization call from being made.
The basic problem appears to be that libc_init_common.c is only built once,
and it's only built for the non-debug libc.
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows libc.so to run the C runtime initializer as soon as the
dynamic linker loads the shared library, i.e. before any other initializers
(e.g. static C++ constructors in other shared libraries the executable depends
on).
This also removes the bug where the initializers from the executable itself
were run twice: once by the dynamic linker, and another time by __libc_init
as defined by libc_init_dynamic.c
|
| |
|
|
|
|
| |
constructors twice."
This reverts commit 03eabfe65e1e2c36f4d26c78a730fa19a3bdada3.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was due to the fact that, in the case of dynamic executables,
the dynamic linker calls the DT_PREINIT_ARRAY, DT_INIT and DT_INIT_ARRAY
constructors when loading shared libraries and dynamic executables,
*before* calling the executable's entry point (i.e. arch-$ARCH/bionic/crtbegin_dynamic.c)
which in turns call __libc_init() in libc.so, as defined by bionic/libc_init_dynamic.c
The latter did call these constructors array again, mistakenly.
The patch also updates the documentation of many related functions.
Also adds a new section to linker/README.TXT explaining restrictions on
C library usage.
The patch has been tested on a Dream for stability issues with
proprietary blobs:
- H264 decoding works
- Camera + Video recording works
- GPS works
- Sensors work
The tests in system/extra/tests/bionic/libc/common/test_static_cpp_mutex.cpp has been
run and shows the static C++ constructor being called only once.
|
| | |
|
| | |
|
| |
|
