Re: Precompiled binaries or compile script needed for Android

[enh <enh () google com>]

On Sat, Jul 21, 2018 at 2:34 PM Michael Richardson <mcr () sandelman ca> wrote:

> enh <enh () google com> wrote:
>     >> security () tcpdump org is not an appropriate place to ask about
> binaries.
>     >> Sometime on tcpdump-workers might be able to help you.
>     >> https://www.androidtcpdump.com/ also is around.
>     >> I don't know who runs it.
>     >>
>     >> I spent some time trying to integrate the Android (ASOP) build
> system
>     >> Makefiles into tcpdump, but it never went upstream, and I ran out of
>     >> time.
>
>     > as the AOSP maintainer of external/tcpdump and external/libpcap, i
> don't
>     > think that would help you or me. it's usually just a pain for us
> when an
>     > upstream project has an Android.mk because then we have to
> coordinate for
>     > build system changes that no-one outside of AOSP actually cares
> about.
>
> And if we could bring you into the fold, then you could maintain the file
> you want?

even for projects where i have an upstream commit bit, it's not helpful to
either side to have the Android.mk in the upstream project. Android's
compiler toolchain gets updated frequently, so it's often necessary to slip
in a -Wno-new-warning-that-a-project-doesn't-care-about or whatever.
there's also the need to work around the mismatch between autoconf (or
equivalent) and Android's single tree for four architectures with generated
files checked in: that sometimes leads to Android.mk effectively taking
over the role of config.h itself.

and at the same time, there's no benefit to upstream from keeping an
Android.mk that's only useful in AOSP and that they can't usually test
themselves anyway. and why would they? even on very beefy machines, an AOSP
build isn't quick. and the download is even worse.

what _would_ be useful:

1. if it was easier for folks to build with the NDK. but we think it scales
better if we get to the point where it's trivial to cross compile. like i
said, if you know how to set up a suitable cross-compilation toolchain you
can already build tcpdump out of the box with configure/make. and as i
said, the next step is to remove the need to set up a cross-compilation
toolchain (
https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md).
and i really need to get around to publishing a script that hides even
that, so it's more of an "apt-get" kind of experience. we're working on
it...

2. if AOSP was always up to date. i know historically a lot of projects
were added to external/ and then left to rot, but my team has been trying
to clean that up, and libpcap/tcpdump were actually fairly early
beneficiaries. i removed all local hacks some time ago and the reason i'm
on this mailing list is because there isn't a separate -announce mailing
list :-)

i have someone working on automating updates of projects hosted on github,
though, so hopefully we'll be able to take the human out of the loop for
libpcap this (1.9.0 release...

    > (luckily since we switched to Android.bp i haven't seen any upstream
>     > project even think it might be a good idea for them to have one of
> those!)
>
> ha.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr () sandelman ca  http://www.sandelman.ca/        |   ruby on
> rails    [
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers