[Aboriginal] Using native-build.sh for An Android native C compiler

[Rob Landley]

On 07/16/2011 02:05 PM, Earlence Fernandes wrote:
>>Have you tried to dlopen() one of the other shared libraries that comes
>>with uClibc just to make sure that the issue is dlopen() and not it
>>being really confused by that particular library?
> 
> I tried it with libm.a shipped with my native compiler. It worked ok!!
> 
> strange that is doesn't open /system/lib/libc.so
> Thoughts?
> 
> -Earlence

Weird, .a files are static libraries, not dynamic libraries.  I didn't
think dlopen could do anything useful with them.  Huh.

Shared libraries have all sorts of funky hooks and things, initializion
code, different types of relocations (REL vs RELA, lazy binding needs
its own extra set of tables, and of course the gnu guys extended elf
with their own hash stuff as blogged about
http://blogs.oracle.com/ali/entry/gnu_hash_elf_sections ...

There's a marvelous set of blog entries on writing a linker by the guy
who did GOLD, it's linked to as reference #1 from the gold wikipedia entry:

  http://en.wikipedia.org/wiki/Gold_(linker)

Denys Vlasenko did a marvelous talk on some linker subtleties he
encountered, the video of which is one of these:

  http://free-electrons.com/blog/elc-2010-videos/

If you want to learn about how linkers work, the standard reference is:

  http://www.iecc.com/linker/

Plus the ELF spec:

  http://refspecs.freestandards.org/elf/

So it's entirely possible something is subtly wrong with that .so
because they wrote their own dynamic linker that doesn't use all the
fields the others do, and thus uClibc's following an unexpected null
pointer or something.  But that's just a guess.

Rob

 1310958129.0