Thank you for the reply.<br><br>1. gb is custom software (sorry I should have made a note of that).<br>2. I rewrote a simple program with one line<br><br>void *dlh = dlopen("/system/lib/libc.so", RTLD_NOW);<br><br>

I tried it on my build - same problem. seg fault.<br>I tried it with the build you sent me, same problem - seg faults again.<br><br>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).<br>

Or would it be possible to link the program against android ldl.a in the first place?<br><br>-Earlence<br><br><div class="gmail_quote">On Sat, Jul 16, 2011 at 7:42 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net">rob@landley.net</a>></span> wrote:<br>

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