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
--- Begin Message ---
> To: [email protected]
> From: Rob Landley <[email protected]>
> Subject: License naming question.
> Date: Tue, 16 Oct 2018 17:57:10 -0500
>
> Hi,
>
> We spoke at Ohio Linuxfest back in 2013 (you attended my Rise and
> Fall of Copyleft talk, and then we talked in the hallway afterwards).
>
> I _think_ I told you about my plans to try to promote public domain
> equivalent licensing, a concept which has a wikipedia page now:
>
> https://en.wikipedia.org/wiki/Public_domain_equivalent_license
>
> For toybox what I did was take the OpenBSD suggested template license
> off their website and remove the half-sentence requiring people to
> copy that specific license text into derived works, and the resulting
> license made it past Google's lawyers! My toybox project has been
> providing the command line for android since Marshmallow
> (https://lwn.net/Articles/629362/) and we're making progress on
> getting android to build under android, the Bionic libc maintainer
> recently sent me a roadmap update about that:
>
> https://github.com/landley/toybox/commit/92b359f00057
>
> I called the resulting license "Zero Clause BSD" (by analogy with
> "Creative Commons Zero" and the existing 4 clause, 3 clause, and 2
> clause BSD licenses), and I even got SPDX approval for it in 2015
> (because Samsung asked me to shortly after Google merged it into
> AOSP, they'd been adding it aftermarket before then and having an
> SPDX identifier for the license simplified their internal bureaucracy).
>
> Then a couple months after SPDX approved it, somebody _else_ submitted
> the same license to Eric Raymond's old Open Source Initiative using
> "Free" in the name, as in Free Software Foundation. (A sadly loaded
> term these days.)
>
> I hadn't known they were still in the license approval business
> (they stopped approving new licenses in... 2012? And I remember
> them explicitly _rejecting_ CC0 saying public domain isn't a license,
> which their FAQ still talks about at
> https://opensource.org/faq#public-domain). But they approved the
> toybox license under a different name, then asked SPDX to retroactively
> change their name for it. (SPDX didn't, but OSI refused to admit
> it made a mistake, even though they said they had a policy to keep
> the names in sync. They hadn't done their homework.)
>
> Now every time the license is considered for a new use, the confusion
> OSI caused tends to derail things:
>
> https://github.com/david-a-wheeler/spdx-tutorial/issues/1
>
> When github itself was considering adding 0BSD to its license
> pulldown (which would have been a big win), I was asked what I
> thought of the naming confusion, and I wrote two long things on my
> rationale with lots of links to earlier stuff, which you can read
> here if you'd like:
>
> https://github.com/github/choosealicense.com/issues/464
>
> Anyway, I recently decided to ask OSI to admit they made a mistake
> and change their name for the license to match what SPDX did, and
> there was unanimous approval...
>
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-September/003519.html
>
> Until the same guy who was objecting last time showed up to continue
> to object. He ignord the "who used it first" axis, and said he
> wanted to know which name was used more today, and then when he
> lost that argument he said he objects to calling something a BSD
> license that isn't using Berkeley's original wording.
>
> My question is: do you object to the name "Zero Clause BSD" for a
> public domain equivalent license that's the OpenBSD suggested
> template license with half a sentence removed?
>
> If you want to stay out of this, I understand. I'm pretty sure I
> asked you this in 2013 before I started pushing the name, and
> wouldn't have if you'd objected then, but that was long ago and the
> water under the bridge is dead...
>
> Thanks for your time, sorry that took so long to explain. (And even
> longer if you read the big long github choosealicense thread. :)
>
> Rob
Thanks for the through explanation of the situation.
I have no objections to the name "Zero Clause BSD" for your license.
I hope that you are successful in getting OSI to change their name
for the license to match what SPDX did.
Kirk McKusick
--- End Message ---
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
