Re: [Toybox] Building AOSP...
On 01/10/2015 05:04 PM, enh wrote: On Thu, Jan 8, 2015 at 10:55 AM, Rob Landley r...@landley.net wrote: Since Toybox made it into Android, I just reinstalled my big machine with Ubuntu 14.04 so I could actually add packages to it (such as the java version the Android Open Source Project wants), and I have downloaded AOSP (overnight, and I had to restart it in the morning), and it is now compiling. (Wow, that's a lot of warnings...) upload your patches to https://android-review.googlesource.com/ :-) Actually my problem right now is I can't get the emulator to run. landley@halfbrick:~/android/aosp$ emulator emulator: WARNING: system partition size adjusted to match image file (550 MB 200 MB) emulator: WARNING: data partition size adjusted to match image file (550 MB 200 MB) SDL init failure, reason is: No available video device I ran the build under screen, which meant the session that the build set a magic environment variable for didn't have access to X11. So I ran another window that _did_ have an X11 context and that failed because it didn't have the magic environment variable(s). So then I tried: landley@halfbrick:~/android/aosp$ ANDROID_PRODUCT_OUT=/home/landley /android/aosp/out/target/product/generic prebuilts/android-emulator /linux-x86_64/emulator emulator: ERROR: You did not specify a virtual device name, and the system directory could not be found. If you are an Android SDK user, please use '@name' or '-avd name' to start a given virtual device (see -help-avd for details). Otherwise, follow the instructions in -help-disk-images to start the emulator So then I started reading -help-disk-images (after a few minutes of trying --help-disk-images and it not knowing what I was talking about because normal --longopt syntax does not apply here), and that told me I needed to manually specify at least 4 images (possibly 9 if you could the writable .img files), so I started googling and http://developer.android.com/tools/help/emulator.html told me I needed to read http://developer.android.com/tools/devices/emulator.html which told me I needed to read http://developer.android.com/tools/devices/index.html which didn't explain how the other context tried to just run it (stymied by X11 not being connected up, not by being unable to find the build output) without me needing to create a new thing or specify multiple files manually on the command line... Which is about the point I wandered away and did something else... I should probably re-run the build so it can set up the magic environment variables again (last time it took 5 hours), except then I get one magic window that might run the emulator due to context I can't reproduce, which seems... awkward. I would actually like to understand it. (Or just boot the darn thing under vanilla qemu, which prebuilt/.../emulator seems to be a fork of? I think?) Does anybody know if there's an actual android operating system channel on IRC? The main #android one is mostly about application development in java, and people reimaging their phones. no idea, sorry. I looked for a mailing list but the discussion groups link on https://source.android.com/source/contributing.html leads to index.html in the same directory. (And I'd probably need to create yet another google account to connect, I think I lost the credentials to the previous one again and the one I use for email is some funky domain account thing a friend set up years ago that has some really strange status and can't use most google services.) Anyway, my short term goal is still to get Aboriginal Linux weaned off of busybox, and then get Linux From Scratch built under the result. And then _after_ that I need to take apart the AOSP build and figure out what the minimal package set to get text mode running under the emulator, and then try to get that rebuilding under itself. traditionally there hasn't been one, but you can try qemu_arm-userdebug. it's _supposed_ to not include a VM or anything though i'm led to believe that right now it's building more than it's supposed to because some unwanted dependency crept in. still probably your best choice though. I think I did build that. What config file stores the lunch answers I gave? (The only dotfile I see in the directory is .repo. There's no output directory. I can't do git status in the directory because it says there's no git repo there. Currently running repo status on a wild guess, but that's spent 2 minutes sitting there without producing any output yet...) Ah it eventually said nothing to commit (working directory clean). There are a whole bunch of output files somewhere, and config files somewhere else. I suppose some wiki page tells me where they are, maybe I'll find it someday. Might be easier to start reading from the top level Makefile on down, let's see, that's a not-symlink to build/core/main.mk, which is a thousand lines long... This will almost certainly involve separating the build into
[Toybox] Why no reading of the spec is a substitute for real world test data.
On 01/08/2015 03:38 PM, Felix Janda wrote: sed doesn't allow embedded newlines in the replacement for s///, e.g. s/walrus/wal\ rus/ It is not obvious to me how to fix this. There is some code for dealing with line continuations but I don't see how to use it. Felix Ok, _now_ sed should have been promoted. I fixed the bugs in all the saved invocations from the aboriginal linux build, and aboriginal is building with the new sed. (I still need to run LFS through the same meat grinder, but hopefully the earlier packages caught the important bugs.) Actually e2fsprogs had most of the truly weird stuff. I don't think that's ever been built with anything _but_ gnu sed. (Or busybox. :) No pretensions of portability... The 4 remaining failing test cases were: 1) Two versions of the one you caught, except that it's not just an escaped newline but _any_ newline. In -f files newline in a delimited string was treated as a literal because the entire file was read and processed as a single line with newlines similar to semicolons. So I hooked up the fetch next line callback logic to branch to 's' or 'a' cases, and saved the current delimiter we were looking for in the 'hit' variable I was shamelessly repurposing to store status already. So my version should work for sed -e 's/blah/one' -e 'two/' as well, which the gnu one doesn't handle but LOGICALLY if you're going to accept one you should accept both... I also added a check for we hit the end of the script and we were still looking for a delimiter, with error message. Because that's a potential failure mode now. (Sort of explains that weird a\ and then no line after it thing that gnu happily accepts. You had a line continuation with no next line! How is that not an error?) 2) Busybox and gnu put an extra newline at the end of a file in one test because posix says N should abort and NOT produce default output when there's no more line to read, and that's not what posix does. (Busybox copies gnu. I followed posix. I'm ok with that test staying different because posix is clear on the correct behavior here and it doesn't actually affect anything in this instance.) 3) There was a test that was just '/thingy/!d;N' so only the line with the regex match and the following line got output. This was failing because when N was the last line of the script the pointer we saved to where to resume in the script was the next command after N, I.E. the null pointer terminating the linked list, and when it called back into the function and saw that TT.resume was NULL it started the script over from the beginning. Oops. I fixed that by adding 1 to the saved pointer and subtracting 1 from resume when we used it, so the saved value was never null. (This involved a typecast on the way back in because TT.resume is null so I don't have to put my structure type into a global header, but subtracting 1 to a void pointer is treated as a char * and it didn't go back to the same original value without the typecast.) (No it can't overflow back to NULL because it would have been pointing into kernel space. Into the VDSO page, I think. Certainly not part of the heap.) Anyway: Sed! Done! I think! That was fiddly. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] Building AOSP...
On Mon, Jan 12, 2015 at 11:35 PM, Rob Landley r...@landley.net wrote: On 01/10/2015 05:04 PM, enh wrote: On Thu, Jan 8, 2015 at 10:55 AM, Rob Landley r...@landley.net wrote: Since Toybox made it into Android, I just reinstalled my big machine with Ubuntu 14.04 so I could actually add packages to it (such as the java version the Android Open Source Project wants), and I have downloaded AOSP (overnight, and I had to restart it in the morning), and it is now compiling. (Wow, that's a lot of warnings...) upload your patches to https://android-review.googlesource.com/ :-) Actually my problem right now is I can't get the emulator to run. landley@halfbrick:~/android/aosp$ emulator emulator: WARNING: system partition size adjusted to match image file (550 MB 200 MB) emulator: WARNING: data partition size adjusted to match image file (550 MB 200 MB) SDL init failure, reason is: No available video device I ran the build under screen, which meant the session that the build set a magic environment variable for didn't have access to X11. So I ran another window that _did_ have an X11 context and that failed because it didn't have the magic environment variable(s). So then I tried: landley@halfbrick:~/android/aosp$ ANDROID_PRODUCT_OUT=/home/landley /android/aosp/out/target/product/generic prebuilts/android-emulator /linux-x86_64/emulator emulator: ERROR: You did not specify a virtual device name, and the system directory could not be found. If you are an Android SDK user, please use '@name' or '-avd name' to start a given virtual device (see -help-avd for details). Otherwise, follow the instructions in -help-disk-images to start the emulator So then I started reading -help-disk-images (after a few minutes of trying --help-disk-images and it not knowing what I was talking about because normal --longopt syntax does not apply here), and that told me I needed to manually specify at least 4 images (possibly 9 if you could the writable .img files), so I started googling and http://developer.android.com/tools/help/emulator.html told me I needed to read http://developer.android.com/tools/devices/emulator.html which told me I needed to read http://developer.android.com/tools/devices/index.html which didn't explain how the other context tried to just run it (stymied by X11 not being connected up, not by being unable to find the build output) without me needing to create a new thing or specify multiple files manually on the command line... Which is about the point I wandered away and did something else... here's what my shell history says i use if i just want a shell: emulator -partition-size 1024 -verbose -show-kernel -no-window if i build x86-64 i can get native speed via: emulator -partition-size 1024 -verbose -show-kernel -no-window -qemu -enable-kvm -m 1024 (assuming you have kvm enabled, of course.) I should probably re-run the build so it can set up the magic environment variables again (last time it took 5 hours), except then I get one magic window that might run the emulator due to context I can't reproduce, which seems... awkward. I would actually like to understand it. (Or just boot the darn thing under vanilla qemu, which prebuilt/.../emulator seems to be a fork of? I think?) certainly the aim is to get back in sync with upstream, but i've no idea where that stands right now. Does anybody know if there's an actual android operating system channel on IRC? The main #android one is mostly about application development in java, and people reimaging their phones. no idea, sorry. I looked for a mailing list but the discussion groups link on https://source.android.com/source/contributing.html leads to index.html in the same directory. (And I'd probably need to create yet another google account to connect, I think I lost the credentials to the previous one again and the one I use for email is some funky domain account thing a friend set up years ago that has some really strange status and can't use most google services.) Anyway, my short term goal is still to get Aboriginal Linux weaned off of busybox, and then get Linux From Scratch built under the result. And then _after_ that I need to take apart the AOSP build and figure out what the minimal package set to get text mode running under the emulator, and then try to get that rebuilding under itself. traditionally there hasn't been one, but you can try qemu_arm-userdebug. it's _supposed_ to not include a VM or anything though i'm led to believe that right now it's building more than it's supposed to because some unwanted dependency crept in. still probably your best choice though. I think I did build that. What config file stores the lunch answers I gave? (The only dotfile I see in the directory is .repo. There's no output directory. I can't do git status in the directory because it says there's no git repo there. Currently running repo status on a wild guess, but
Re: [Toybox] Building AOSP...
On 01/13/2015 12:02 PM, enh wrote: On Mon, Jan 12, 2015 at 11:35 PM, Rob Landley r...@landley.net wrote: On 01/10/2015 05:04 PM, enh wrote: On Thu, Jan 8, 2015 at 10:55 AM, Rob Landley r...@landley.net wrote: Since Toybox made it into Android, I just reinstalled my big machine with Ubuntu 14.04 so I could actually add packages to it (such as the java version the Android Open Source Project wants), and I have downloaded AOSP (overnight, and I had to restart it in the morning), and it is now compiling. (Wow, that's a lot of warnings...) upload your patches to https://android-review.googlesource.com/ :-) Actually my problem right now is I can't get the emulator to run. landley@halfbrick:~/android/aosp$ emulator emulator: WARNING: system partition size adjusted to match image file (550 MB 200 MB) emulator: WARNING: data partition size adjusted to match image file (550 MB 200 MB) SDL init failure, reason is: No available video device I ran the build under screen, which meant the session that the build set a magic environment variable for didn't have access to X11. So I ran another window that _did_ have an X11 context and that failed because it didn't have the magic environment variable(s). So then I tried: landley@halfbrick:~/android/aosp$ ANDROID_PRODUCT_OUT=/home/landley /android/aosp/out/target/product/generic prebuilts/android-emulator /linux-x86_64/emulator emulator: ERROR: You did not specify a virtual device name, and the system directory could not be found. If you are an Android SDK user, please use '@name' or '-avd name' to start a given virtual device (see -help-avd for details). Otherwise, follow the instructions in -help-disk-images to start the emulator So then I started reading -help-disk-images (after a few minutes of trying --help-disk-images and it not knowing what I was talking about because normal --longopt syntax does not apply here), and that told me I needed to manually specify at least 4 images (possibly 9 if you could the writable .img files), so I started googling and http://developer.android.com/tools/help/emulator.html told me I needed to read http://developer.android.com/tools/devices/emulator.html which told me I needed to read http://developer.android.com/tools/devices/index.html which didn't explain how the other context tried to just run it (stymied by X11 not being connected up, not by being unable to find the build output) without me needing to create a new thing or specify multiple files manually on the command line... Which is about the point I wandered away and did something else... here's what my shell history says i use if i just want a shell: emulator -partition-size 1024 -verbose -show-kernel -no-window $ cd android/aosp $ prebuilts/android-emulator/linux-x86_64/emulator -partition-size 1024 -verbose -show-kernel -no-window emulator:Can't determine target AVD architecture: defaulting to arm emulator:Looking for emulator-arm to emulate 'arm' CPU emulator:Probing program: prebuilts/android-emulator/linux-x86_64/emulator64-arm emulator:Found target-specific emulator binary: prebuilts/android-emulator/linux-x86_64/emulator64-arm emulator:Probing for: prebuilts/android-emulator/linux-x86_64/libOpenglRender.so emulator:Probing for: prebuilts/android-emulator/linux-x86_64/lib/libOpenglRender.so emulator:Found OpenGLES emulation libraries in prebuilts/android-emulator/linux-x86_64/lib emulator:Setting LD_LIBRARY_PATH=prebuilts/android-emulator/linux-x86_64/lib emulator: ERROR: You did not specify a virtual device name, and the system directory could not be found. If you are an Android SDK user, please use '@name' or '-avd name' to start a given virtual device (see -help-avd for details). Otherwise, follow the instructions in -help-disk-images to start the emulator [Clearly I have no idea what I'm doing. As usual...] if i build x86-64 i can get native speed via: emulator -partition-size 1024 -verbose -show-kernel -no-window -qemu -enable-kvm -m 1024 (assuming you have kvm enabled, of course.) I should probably re-run the build so it can set up the magic environment variables again (last time it took 5 hours), except then I get one magic window that might run the emulator due to context I can't reproduce, which seems... awkward. I would actually like to understand it. (Or just boot the darn thing under vanilla qemu, which prebuilt/.../emulator seems to be a fork of? I think?) certainly the aim is to get back in sync with upstream, but i've no idea where that stands right now. If there's a list for it, I'd be interested. I'm slowly poking at qemu internals more... I think I did build that. What config file stores the lunch answers I gave? (The only dotfile I see in the directory is .repo. There's no output directory. I can't do git status in the directory because it says there's no git repo there. Currently running repo status on a wild guess, but that's spent 2 minutes sitting
