On Sat, Dec 2, 2017 at 11:16 PM, Rob Landley <r...@landley.net> wrote:
> On 04/28/2017 05:31 PM, enh wrote:
>> since rob asked on some other thread earlier this week...
>>
>> NDK r15beta2 should hopefully ship in time for I/O in a couple of weeks,
>> so i had a quick go at building toybox out of the box with the latest
>> bits...
>
> By the way, I've been meaning to ask:
>
> $ /opt/android/x86_64/bin/clang --static -s hello.c && ls -l a.out
> -rwxrwxr-x 1 landley landley 485880 Dec 2 22:10 a.out
>
> $ ~/mcm/bin/x86_64-linux-musl-cc hello.c -s --static && ls -l a.out
> -rwxrwxr-x 1 landley landley 17584 Dec 2 22:16 a.out
>
> $ cat hello.c
> #include <stdio.h>
>
> int main(int argc, char *argv[])
> {
> printf("hello world %d\n", 5);
>
> return 0;
> }
>
> Did that ever become... less bad? Yes, I'm forcing printf to do
> something so gcc can't "optimize" it to puts, so it's a fair test. But
> this seems to mostly be a "strip didn't" issue? A "grep -ai bionic" on
> the stripped bionic binary (manually re-stripped to make sure) produced
> stuff like:
very short version: the libc.a in the NDK hasn't changed in years
(https://github.com/android-ndk/ndk/issues/272).
but a current arm/arm64 static "hello world" is still large. it's not
something we care about. other than the dynamic linker, init and adbd
Android doesn't really use static binaries. (and once we can ignore
devices where / and /system aren't the same partition, we'll switch
init and adbd over too.)
> 0123456789ABCDEF0123456789abcdefconversion specifier
> unsupportedbionic/libc/bionic/libc_logging.cppFORTIFY_SOURCE: %s.
> Calling abort().open(O_CREAT): called without specifying a
> modeopenat(O_CREAT): called without specifying a modeNo [stack] line
> found in /proc/self/maps!pthread_create sched_setscheduler call failed:
> %spthread_create failed: couldn't allocate threadpthread_create failed:
> couldn't allocate %zd-byte stack: %spthread_create failed: couldn't
> mprotect PROT_NONE %zd-byte stack guard region: %spthread_create failed:
> clone failed: %sMath argument out of domain of funcToo many symbolic
> links encounteredValue too large for defined data typeCan not access a
> needed shared libraryAccessing a corrupted shared library.lib section in
> a.out corruptedAttempting to link in too many shared librariesCannot
> exec a shared library directlyInterrupted system call should be
> restartedSocket operation on non-socketProtocol wrong type for
> socketOperation not supported on transport endpointAddress family not
> supported by protocolCannot assign requested addressNetwork dropped
> connection because of resetSoftware caused connection abortTransport
> endpoint is already connectedTransport endpoint is not connectedCannot
> send after transport endpoint shutdownToo many references: cannot
> splice%s(3) is not implemented on Android
> strchr: prevented read past end of
> bufferbionic/libc/upstream-netbsd/lib/libc/string/strcoll.cvoid
> endusershell()void setusershell()char* getusershell()void
> endpwent()/dev/socket/property_service
>
> (Although I'm pretty sure the strchr warning near the end there is
> ubuntu 14.04's grep being buggy. Did I mention I break everything?)
no, that's one of our FORTIFY warnings. and printf calls strchr, so
that's not particularly surprising. something in the libc startup code
probably calls strerror, bringing in the big chunk of strerror strings
in the middle. pthreads aren't an optional extra to us, so every
program sets up the main thread ready for when the next thread is
created (which is the performance case for us), and that kind of
startup stuff seems to cover the rest of those.
and looking at the symbols with nm, i see all of jemalloc plus things
that are either potentially called by printf (if not for that
particular format string) or as part of libc startup. it all looks
plausible to me. and your numbers above are half the size i see from
building the same test with glibc :-)
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
