Help building toybox with the NDK/bionic about toybox HOT 9 CLOSED

Sorry, busy couple of days. I hope to catch up this weekend.

Rob

On 08/12/2016 04:07 AM, Michael Eder wrote:

I'm having the same issue, using ndk-r12b

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#43 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/ABWXCR3Gi6CdjA1-ou676_Z95_VUglQvks5qfDe1gaJpZM4JitBt.

from toybox.

I'm having the same issue, using ndk-r12b

from toybox.

On 08/11/2016 08:25 PM, Matthias Urhahn wrote:

I've tried to setup the latest NDK to test #36
#36. I followed the
instructions here
https://developer.android.com/ndk/guides/standalone_toolchain.html, to
export a standalone toolchain.

I hadn't found that page before, so I gave it a try.

The NDK download page is
https://developer.android.com/ndk/downloads/index.html and the linux
version is a 750 megabyte download, which ground away through through
coffee shop wifi at about 120k/second for the rest of that evening so I
didn't get back to it for a few days.

When I did, I got hello world to build:

android-ndk-r12b$ toolchains/x86_64-4.9/prebuilt/linux-x86_64
/bin/x86_64-linux-android-gcc --static hello.c
--sysroot=$PWD/platforms/android-24/arch-x86_64

Which was a little bit awkward and the resulting a.out is over 3 megs.
Stripping it brings it down to 489984 bytes for basically a call to
printf(). Still, it ran.

This email has now been sitting open on my desktop for 3 days with no
further progress, so I should probably just send it. :)

Next up, I should try building toybox with it and see what happens.

Rob

from toybox.

NDK r14 beta 1 should be out next week and includes the unified (aka "modern") headers, which will be the first step towards building toybox with the NDK.

(for the foreseeable future though, building toybox from an AOSP tree is the only really practical option.)

from toybox.

On 11/19/2016 01:54 PM, Elliott Hughes wrote:

NDK r14 beta 1 should be out next week and includes the unified (aka
"modern") headers, which will be the first step towards building toybox
with the NDK.

Yay!

(for the foreseeable future though, building toybox from an AOSP tree is
the only really practical option.)

I have a todo item to try again to get a bionic toolchain working here
(I've got glibc, musl-libc, and some old uClibc toolchains I'm not using
much anymore, for a half-dozen architecture targets), so I'm happy to
poke at the new ndk when it comes out.

That said, what little bandwidth I've managed to scrape up for test
build environment work recently went to
http://lists.landley.net/pipermail/aboriginal-landley.net/2016-November/002591.html
and that's the test environment I'm hoping to have working again by new
year's. (Working as in maybe building linux from scratch under toybox
again, which I haven't done in a couple releases now.)

I note that the new "make airlock" target is partly intended to
contribute to eventual hermetic builds of AOSP, but I know that
generated/ not being a symlink is screwing you up and some stuff like
that. I read https://lwn.net/SubscriberLink/706404/9f66d57a520d6d8c/ and
may try to do a ninja version at some point, but work's been nuts for a
while now and I'm still not sure when that's letting up. Just trying to
keep up with the bug reports in realtime is a bit of a juggling act...

Speaking of which, I see you're going through the github bug reports and
recommending closing several. Thanks for doing tidying I've never
bothered? I treat the emails those send me as any other personal email
with a bug report (except that I don't have to ask permission to forward
my replies to the list because they're already public). So in THEORY
I've dealt with them all. In practice, stuff tends to fall through the
cracks when I'm overwhelmed. :(

(The downside of using github for distribution is it has its own tool
ecosystem which tries to be "sticky", and doesn't really give you the
option to not use it. Engaging with those enough to close them would
sort of be encouraging them? (I can if people really want it, but having
seen sourceforge and savannah and so on come and go, I'm reluctant to
tie project development tightly to a specific site's infrastructure
unless I'm the one maintaining it. I'm aware dreamhost's mailing list
infrastructure makes this hilarious, yes, but I'm at least the one
paying for that, and technically can extract mbox files out of that
mess and assemble new archives if I really have to...)

Rob

from toybox.

Just happen to perform a quick check on master branch with HEAD commit 1c336a9 (2018 Oct 06)
I can only successfully build 1c336a9 provided I reverted these 2 commits.

Reverts commit 951c733. (2018 Oct 06)
Reverts commit b33d37d. (2018 Sep 27)

• Unzip NDK r18 and setup NDK standalone toolchain using:

./build/tools/make-standalone-toolchain.sh \
    --toolchain=aarch64-linux-android-4.9 \
    --arch=arm64 \
    --stl=libc++ \
    --package-dir=${HOME}/local/ndk-package \
    --install-dir=${HOME}/local/android-toolchain \
    --platform=android-28 \
    --force

• Required patching NDK r18 broken script which redirect gcc to clang due to gcc removal.

sed s#/../../../../llvm/prebuilt/linux-x86_64/bin##g -i ${HOME}/local/android-toolchain/bin/aarch64-linux-android-gcc
sed s#/../../../../llvm/prebuilt/linux-x86_64/bin##g -i ${HOME}/local/android-toolchain/bin/aarch64-linux-android-g++

from toybox.

r18b should be out soon fixing the fake gcc wrappers (but it's time to move off them anyway).

following the instructions on https://developer.android.com/ndk/guides/standalone_toolchain and building myself, i see that the problem is that libcutils isn't in the NDK. i've sent a patch to the list making the Android platform vs Android NDK distinction.

from toybox.

time to close this issue?

from toybox.

Yup.

from toybox.