On Sun, May 8, 2011 at 12:52 AM, Steev Klimaszewski
> > What overlay? I feel like I either missed part of this conversion, or there
> > is an overlay that I don't know about.
> My guess would be, the overlay he is doing this work in, so as to make
> it public, once it actually works and people can use it, rather than
> posting it in an unworkable state and having a million emails asking
> why this or that isn't working.
Good guess :)
My main goal was to get this overlay up to speed with my last project
that involved running jamvm atop bionic. The only difference here is
that the other project was done with the Android build system while
this one is using portage.
Busybox works right now in my chroot environment (rpc, nfs, and a
couple of other things are disabled for now). Library search paths
were set to /lib and /usr/lib by default, so I don't need to set
LD_LIBRARY_PATH anymore. Resolv is working. Need to add some things
like crypt(3), getpwent(3), etc.
The libc itself has several 'stubs' that print a 'fixme' message to
stderr whenever invoked, and return NULL / -1 / errno=ENOSYS.
The end result [current staus] will more or less be the following:
[working aside from stubs]
bionic (libc, libm, libthread_db, libstdc++) [libc has some stubs]
icu4c [needs a c++ compiler]
libxml2 [working, needs to be rebuilt and linked with icu4c]
libxslt [depends on working libxml2 w/ icu4c]
file (libmagic) [working]
This setup (all the way to jamvm) is actually working quite well on 2
architectures right now (i686 & arm) when built using the Android
build system, so I'll be happy when it's working using portage,
because manual building / scripting from autotools to plain make is
getting painful when I'm just adding a new library to the build.