Why bionic contain static and dynamic libc library?

[Kerr]

bionic/libc/Anroid.mk, It builds libc.a and libc.so, 

But I think only libc.so is enough, so why do we need libc.a?

Anyone is clear about this?

Kerr

[Liu Xin]

as far as i knew, init and linker itself use static libc or a subset of libc. 

linker takes responsible for loading other dynamic libraries.  it's hard to load libc.so first. 

thanks,

--lx

Kerr

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Turner]

On Thu, Mar 21, 2013 at 3:58 AM, Kerr <yuan...@gmail.com> wrote:

bionic/libc/Anroid.mk, It builds libc.a and libc.so, 

But I think only libc.so is enough, so why do we need libc.a?

A few executables _definitely_ need to be static executables, i.e. cannot rely on the dynamic linker (init, adbd and a few others). That's why a static library version is needed.

Also, the dynamic linker itself is statically linked against a "reduced" version of the C library.

 

Anyone is clear about this?

Kerr

--

[Jean-Baptiste Queru]

A good brute-force trick to know that is to remove the build rule for
the static library, try to do a build, and see what breaks.

JBQ

> --
> You received this message because you are subscribed to the Google Groups
> "android-platform" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-platfo...@googlegroups.com.
> To post to this group, send email to android-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/android-platform?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Kerr Yuandan]

Of course, because some library depend on libc.a, so when we remove .a, it will fail. But the log info is no useful.

====================

make: *** No rule to make target `out/target/product/maguro/obj/STATIC_LIBRARIES/libc_intermediates/export_includes', needed by `out/target/product/maguro/obj/EXECUTABLES/charger_intermediates/import_includes'.  Stop.

====================

In principle, dynamic linker(interpreter) can be dynamic linked with libc.so, it's not a problem, so why did you link it with a "reduced " statically library. By this way, the libc object code will be loaded in system memory twice. One(libc.a) for dl itself, and another(libc.so) for  other process to share. I noticed that libc.a size is more than 3M, but libc.so size is only about 300K, I don't dig deep into the compile and link procedure internal.

init process is the first user space process, why can't it use dynamic linker? When kernel do_excutec() and create init process, kernel will check the interpreter(dynamic linker) in init, and load dl.so, then load libc.so(because dl generally depend on it), and then back to init process itself, that's not a problem.

adbd is also can depend on libc.so as init.

So I can not clear in principle why do we need a static libc?

Kerr

[Kerr Yuandan]

I think, the only reason why we need libc.a is that dynamic linker must NOT depend on itself. 

For another word, libdl.so is a static executable in fact.

[cary....@gmail.com]

Some execute module need to be static linked, like init and linker itself. So we need a static version.
android's linker is not the same as gcc ld.so, you can find its files in bionic/linker.

[David Turner]

On Sat, Mar 23, 2013 at 3:47 AM, Kerr Yuandan <yuan...@gmail.com> wrote:

Of course, because some library depend on libc.a, so when we remove .a, it will fail. But the log info is no useful.

====================

make: *** No rule to make target `out/target/product/maguro/obj/STATIC_LIBRARIES/libc_intermediates/export_includes', needed by `out/target/product/maguro/obj/EXECUTABLES/charger_intermediates/import_includes'.  Stop.

====================

In principle, dynamic linker(interpreter) can be dynamic linked with libc.so, it's not a problem, so why did you link it with a "reduced " statically library.

No, that doesn't work like that at all. Even on a regular Linux distribution /lib/ld-linux.so.2 is not a dynamic executable and can't be dynamically linked to libc.so.

In theory, we could statically link it to the full libc.a, but this generates a binary that will be significantly larger for no good reason, due to the cost of internal dependencies in the C library. Using a "reduced" static libc.a makes the final dynamic linker much smaller, and faster to load. This makes starting _any_ executable on the system faster too.

 

By this way, the libc object code will be loaded in system memory twice. One(libc.a) for dl itself, and another(libc.so) for  other process to share. I noticed that libc.a size is more than 3M, but libc.so size is only about 300K, I don't dig deep into the compile and link procedure internal.

Yes, the libc object code is loaded twice. That's also why a "reduced" version is used.

 

init process is the first user space process, why can't it use dynamic linker?

init cannot be a dynamically linked process because when it is launched /system is not mounted, so you can't access /system/bin/linker or /system/lib/libc.so

It would be possible to move these files to the boot partition, but that would make them difficult to update during platform development (it's impossible to change the content of the boot partition at runtime, unlike using "adb sync" which changes the content of /system).

Also, dynamic linking introduces failure modes that are unrecoverable when init is run. Having a single static binary is just simpler and safer.

 

When kernel do_excutec() and create init process, kernel will check the interpreter(dynamic linker) in init, and load dl.so, then load libc.so(because dl generally depend on it), and then back to init process itself, that's not a problem.

No, the kernel never loads dependent libraries for the ELF interpreter. Doing so would require a full dynamic linker in the kernel, which doesn't exist.