B2G icon indicating copy to clipboard operation
B2G copied to clipboard

Investigate using a more complete libc

Open joneschrisg opened this issue 13 years ago • 4 comments

bionic has not been a source of joy for gecko hackers. It would save us some pain (and probably subtle threading bugs) to import a more complete libc. We have a few options

  • ICS bionic. It's likely to be more complete and have better threading support.
  • uClibc
  • eglibc

There are some issues with importing a new libc

  • unexpected ABI issues, or programs relying on undefined or non-standard or buggy behavior that happens to be a particular way in bionic
  • perf changes
  • uClibc and eglibc are copyleft, so vendor modifications need to be released

This isn't high priority but we should keep it in mind.

joneschrisg avatar Jan 06 '12 07:01 joneschrisg

I spent a few hours trying to switch us to uClibc a while back. The biggest difficulty I encountered is that the NDK compiler is built to use bionic. So it appeared, during my brief experiment with this, that we'd have to recompile GCC in order to make this work.

Now, in theory, something like buildroot [1] makes recompiling GCC and libc easy. But I couldn't get it to work.

[1] http://buildroot.uclibc.org/

jlebar avatar Jan 06 '12 15:01 jlebar

Another thing we may suffer is some vendor's BSP codes are linked to bionic by default, and they're often binaries.

jamesho86 avatar Jan 11 '12 03:01 jamesho86

Would substituting uclibc for bionic in those cases be a problem? It should work from the standpoint of the dynamic linker, right? But maybe not from the standpoint of code which works around quirks of bionic.

Another problem is be that we'd be diverging from the libc used by Fennec on Android. (Unless we statically linked in uclibc there? But then you wouldn't be able to build Fennec with the NDK. :-/)

jlebar avatar Jan 11 '12 05:01 jlebar

@jlebar you can use gcc specs or command line args to force it stop using bionic. You don't need to build your owned gcc and binutils.

For the daemon or executable that is already linked with bionic, it is not a big issue. We can use two rtld (linker and ld.so) concurrently. (see INTERP in program headers of ELF executable) For the libraries that is compiled & linked with bionic, our programs have to linked with, and they are provided in binary only, they will introduce bionic into the process. They are real big problem.

ThinkerYzu avatar Jan 31 '12 07:01 ThinkerYzu