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

[Earlence Fernandes]

Thank you for the reply.

1. gb is custom software (sorry I should have made a note of that).
2. I rewrote a simple program with one line

void *dlh = dlopen("/system/lib/libc.so", RTLD_NOW);

I tried it on my build - same problem. seg fault.
I tried it with the build you sent me, same problem - seg faults again.

Is it possible to write a program precompiled with Android's dynamic linker
that will bootstrap the uclibc version? (I know going off topic here).
Or would it be possible to link the program against android ldl.a in the
first place?

-Earlence

On Sat, Jul 16, 2011 at 7:42 PM, Rob Landley <rob at landley.net> wrote:

> On 07/16/2011 12:16 PM, Earlence Fernandes wrote:
> > ok. doing what was suggested in that link got it compiled.
> >
> > I compile my file like the following:
> >
> > gcc -static gb.c -ldl
>
> Would I be familiar with this gb.c software, or is it home-grown?
>
> > however, when I run it, it segfaults in the call to dlopen
> >
> > This is the line in the file:
> >
> > void *dlh = dlopen("/system/lib/libc.so", RTLD_NOW);
>
> Hmmm...  A statically linked uClibc program calling a dlopen() is
> sufficiently black magic that I'd ask the uClibc developers on their
> mailing list.  (You're using a dynamic linker that isn't loaded, there's
> sort of a chicken and egg problem accessing it...)
>
> A quick google finds:
>
>  http://lists.uclibc.org/pipermail/uclibc/2005-July/033038.html
>  http://lists.uclibc.org/pipermail/uclibc-cvs/2005-July/019085.html
>
> Which suggests it was fixed ages ago and should work now, but there
> might have been a regression...
>
> I know that this _should_ work on an android kernel, people use android
> kernels with glibc userspace all the time so no reason it shouldn't work
> with uClibc.  So it's 99% likely to be just a uClibc bug.
>
> One thing to try is using the current 0.9.32 release of uClibc.  I just
> put a temporary copy of that at:
>
>  http://landley.net/native-compiler-armv5l.tar.bz2
>
> I note this hasn't been nearly as tested as the 0.9.31 version I'm
> using.  That's their new release that came out recently.  (It includes
> NTPL support, although I believe I've compiled it for pthreads at the
> moment.)
>
> If that works for you, it should be in the next release (aiming for the
> end of the month).
>
> Another thing to try is installing the shared libraries on the android
> host, in their own directory, and doing a dynamically linked version.
> That's a touch more complicated though.  (I have support for doing this
> at non-standard paths, but don't remember the name of the control knobs
> off the top of my head and it's been a while since I tested it.  I can
> look it up if you're interested and write up documentation on how to do
> it.  Fixing the static linking bug might be easier, especially if
> there's an existing patch or easy workaround...)
>
> > -Earlence
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20110716/d46adb73/attachment-0003.htm>