[Toybox] [PATCH] libcutils isn't in the NDK.

[Rob Landley]

On 10/17/2018 04:51 PM, enh wrote:
> i think what you have is broken even for static builds, since you have
> an ODR violation from the missing `static inline` on your no-op
> function:
> 
> ld.lld: error: duplicate symbol: __android_log_write
>>>> defined at portability.h:282 (external/toybox/lib/portability.h:282)
>>>>            out/soong/.intermediates/external/toybox/toybox_vendor/android_arm64_armv8-a_cortex-a73_vendor/obj/external/toybox/lib/args.o:(__android_log_write)
>>>> defined at portability.h:282 (external/toybox/lib/portability.h:282)
>>>>            out/soong/.intermediates/external/toybox/toybox_vendor/android_arm64_armv8-a_cortex-a73_vendor/obj/external/toybox/toys/android/setprop.o:(.text.__android_log_write+0x0)

Hmmm... it built for me, but yes it seems to screw up dynamic builds with the
ndk. Blah. (I wasn't building that here because I can't run it locally.)

I'd love to be able to use the NDK to build a dynamic mkroot root filesystem,
but I don't think I can beat a native comiler out of this install script (can
I?) and dynamic library installation out of a toolchain is... fraught.

I've tried to make it work before, and I think I left off at
https://github.com/landley/mkroot/blob/master/module/dynamic
(which is just a mess).

It's on my todo heap. :)

The big design change between aboriginal linux and mkroot is outsourcing the
toolchains, both source and native, to an external package. Which means
outsourcing the C library build if your target is going to be dynamically
linked, which means installing those binaries _from_ the toolchain, which is
kinda hard to do in a toolchain-agnostic manner. Which relates to my old "six
paths" rant from the dark ages, which google says is in
https://landley.net/ols/ols2007/cross-compiling.html and I _know_ is buried in
the video of the compiler BOF I hosted the next year...

I was actually interested in building bionic from source and slotting it into an
existing toolchain or root filesystem, but there's no makefile or build shell
script for it, I'd have to get ninja working. And the version of ninja installed
in Ubuntu was too old to build AOSP when I tried, I'd have to build tools to
create an environment to build other tools with...

As I said, todo items.

> why am _i_ seeing this building for the platform? because we screwed
> up and __ANDROID_NDK__ was actually getting defined there. thanks for
> finding that :-)

I break everything.

I added "test NDK dynamic build" to the todo list for the release. Alas, I
wasted the past few days arging with OSI about their misnaming of the toybox
license:

Pass 1:

http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-September/003519.html

Unanimous assent for doing what I asked.

Pass 2:

http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003581.html

Richard Fontana objects nine times, he's the only one who ever tried to push
back against SPDX back in 2015, every other objection is a "me too" reply to
Richard Fontanta (from non-members of OSI), and of course "I googled and found
stuff I won't link to, then when asked for links I say I haven't work to
recreate the search because about:history does not exist":

http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003653.html

That's the most recent message I've replied to on the list. Bit of a bad taste
in my mouth at this point.

It's possible soliciting the attached email _might_ have been overkill, but
license arguments make me tetchy. (Kirk was the longest serving maintainer of
the original BSD back at the Berkeley CSRG. The full open source release
happened on his watch.)

Ahem. So... a bit distracted recently. Sorry about that.

Rob
-------------- next part --------------
An embedded message was scrubbed...
From: Kirk McKusick <mckusick at mckusick.com>
Subject: Re: License naming question.
Date: Wed, 17 Oct 2018 11:01:40 -0700
Size: 7755
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20181017/db1e13d6/attachment-0003.eml>