From rob at landley.net Mon Aug 4 14:42:11 2014 From: rob at landley.net (Rob Landley) Date: Mon, 04 Aug 2014 09:42:11 -0500 Subject: [Aboriginal] Hello world. / kernel 3.15 In-Reply-To: <6342240.LNGOc1HuLi@localhost> References: <53D9B1EA.606@landley.net> <6342240.LNGOc1HuLi@localhost> Message-ID: <53DF9BC3.3060904@landley.net> On 07/30/14 23:47, Patrick Lauer wrote: > On Wednesday 30 July 2014 22:03:06 Rob Landley wrote: > >> I did some toybox work during all this on my netbook, but almost no >> aboriginal work. Next kernel release is almost out. I think I've missed >> one. > > No worry, I hackpatched things to work with 3.15. > > Patches apply modulo one change in the sh4 config where an option got renamed. "Patches apply" and "result works on all targets well enough to build LFS" have historically had a shaky relationship, but thanks for the heads up. :) I've been poking at things like what binutils is doing with -Bsymbolic-functions (not "the right thing") and getting toybox find so it can drop in replace busybox find (now it needs -maxdepth). I need to cut a release with the 3.15 kernel still using/defaulting uClibc, but letting you use musl with a config symbol. Might just do MUSL=1 for that, so: MUSL=1 ./build.sh i586 (Of course how would it know that there's no musl support for sparc yet, but it could _try_ to build...) > toybox reliably fails to build iconv (missing iconv.h ), so I violently > patched that out of the default config. I fixed that in source control, next release should have that. Next toybox release should be the end of the month, and I can do an aboriginal with 3.16 then to catch up. > Enjoy, > > Patrick > > diff -Naur ../../aboriginal-1669660a7a97/download.sh ./download.sh > --- ../../aboriginal-1669660a7a97/download.sh 2014-07-12 22:04:12.000000000 > +0000 > +++ ./download.sh 2014-07-31 04:32:03.833672950 +0000 > @@ -29,8 +29,8 @@ > SHA1=aa6c4e58ee3524b961755fb8e491462ff8109fd6 \ > maybe_fork "download || dienow" > > -URL=ftp://kernel.org/pub/linux/kernel/v3.x/linux-3.14.tar.gz \ > -SHA1=23fde5cfe36e27eca54947744613b45e747d18e9 \ > +URL=ftp://kernel.org/pub/linux/kernel/v3.x/linux-3.15.7.tar.gz \ > +SHA1=19ca216acc59e5445566f7aff06db5651d1a8185 \ > maybe_fork "download || dienow" > > > diff -Naur ../../aboriginal-1669660a7a97/sources/patches/linux- > sh4noexpert.patch ./sources/patches/linux-sh4noexpert.patch > --- ../../aboriginal-1669660a7a97/sources/patches/linux-sh4noexpert.patch > 2014-07-12 22:04:12.000000000 +0000 > +++ ./sources/patches/linux-sh4noexpert.patch 2014-07-31 03:33:30.696424896 > +0000 > @@ -11,5 +11,5 @@ > - select EXPERT > + select HAVE_PATA_PLATFORM > select CLKDEV_LOOKUP > - select HAVE_IDE if HAS_IOPORT > + select HAVE_IDE if HAS_IOPORT_MAP > select HAVE_MEMBLOCK > diff -Naur ../../aboriginal-1669660a7a97/sources/patches/toybox-no-i18n.patch > ./sources/patches/toybox-no-i18n.patch > --- ../../aboriginal-1669660a7a97/sources/patches/toybox-no-i18n.patch > 1970-01-01 00:00:00.000000000 +0000 > +++ ./sources/patches/toybox-no-i18n.patch 2014-07-31 04:06:48.503403651 > +0000 > @@ -0,0 +1,10 @@ > +--- toybox-0.4.8/Config.in > ++++ toybox-0.4.8/Config.in > +@@ -51,7 +51,7 @@ > + > + config TOYBOX_I18N > + bool "Internationalization support" > +- default y > ++ default n > + help > + Support for UTF-8 character sets, and some locale support. I18N support and iconv aren't directly related. This lets wc -m work. > diff -Naur ../../aboriginal-1669660a7a97/sources/patches/toybox-no-iconv.patch > ./sources/patches/toybox-no-iconv.patch > --- ../../aboriginal-1669660a7a97/sources/patches/toybox-no-iconv.patch > 1970-01-01 00:00:00.000000000 +0000 > +++ ./sources/patches/toybox-no-iconv.patch 2014-07-31 04:24:18.106660446 > +0000 > @@ -0,0 +1,10 @@ > +--- toybox/toys/pending/iconv.c > ++++ toybox/toys/pending/iconv.c > +@@ -8,7 +8,7 @@ > + > + config ICONV > + bool "iconv" > +- default y > ++ default n > + help > + usage: iconv [-f FROM] [-t TO] [FILE...] > > _______________________________________________ > Aboriginal mailing list > Aboriginal at lists.landley.net > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net I think I've fixed that now. I'll try to get a new release out this coming weekend. Thanks, Rob 1407163331.0 From tbird20d at gmail.com Wed Aug 13 23:58:09 2014 From: tbird20d at gmail.com (Tim Bird) Date: Wed, 13 Aug 2014 16:58:09 -0700 Subject: [Aboriginal] /usr/src <-> README mismatch Message-ID: Hey Rob, I've been playing around with aboriginal, and I noticed a discrepancy between the contents of /usr/src (for system-image-armv6l) and the online README. The README says you can do: cc /usr/src/hello.c but there is no hello.c in /usr/src: (armv6l:1) /home # ls /usr/src MANIFEST config-linux hello.cpp thread-hello.c config-busybox config-uClibc host-info thread-hello2.c I tried "cc /usr/src/thread-hello.c" and got the following: (armv6l:1) /home # cc /usr/src/thread-hello.c /tmp/cc42f7aq.o: In function `main': thread-hello.c:(.text+0x58): undefined reference to `pthread_create' I tried "cpp /usr/src/hello.cpp", and got this: /home # cpp /usr/src/hello.cpp # 1 "/usr/src/hello.cpp" # 1 "" # 1 "" # 1 "/usr/src/hello.cpp" /usr/src/hello.cpp:1:20: error: iostream: No such file or directory using namespace std; int main() { cout << "hello world" << endl; return 0; } I wrote my own hello.c in my home directory, and things worked fine. None of this is major stuff - just a slight discrepancy between the image contents and the README, but I thought I'd report it anyhow. Thanks for all your great work! -- Tim Bird Senior Software Engineer, Sony Mobile Architecture Group Chair, CE Workgroup, Linux Foundation 1407974289.0 From rob at landley.net Thu Aug 14 20:59:14 2014 From: rob at landley.net (Rob Landley) Date: Thu, 14 Aug 2014 15:59:14 -0500 Subject: [Aboriginal] /usr/src <-> README mismatch In-Reply-To: References: Message-ID: On Wed, Aug 13, 2014 at 6:58 PM, Tim Bird wrote: > Hey Rob, Hello. I just posted over on the toybox list about my email+backup machine having died tuesday. (In the past month my house got flooded, the dog suddenly died... honestly I'm expecting something to eat my homework any day now. This would sound like a horrible array of excuses except it KEEPS HAPPENING TO ME. Grrr.) Oh, and the kernel guys went INSANE and checked in commit 5d2acfc7b974 which breaks THE VERY IDEA OF MINICONFIG. So I have to revert that to get a release out. That took a while to bisect. (And I completely rewrote your find.c submission, FYI.) > I've been playing around with aboriginal, and I noticed a discrepancy between > the contents of /usr/src (for system-image-armv6l) and the online README. > > The README says you can do: > > cc /usr/src/hello.c > > but there is no hello.c in /usr/src: > > (armv6l:1) /home # ls /usr/src > MANIFEST config-linux hello.cpp thread-hello.c > config-busybox config-uClibc host-info thread-hello2.c Sigh. There should be one. I 99% of the time test with thread-hello2.c, which is a threaded hello world program that actually tests mutex and event semaphores to pass the string to be printed through a shared memory mailbox. (It doesn't test TLS, but gets all the the pthreads stuff.) > I tried "cc /usr/src/thread-hello.c" and got the following: > > (armv6l:1) /home # cc /usr/src/thread-hello.c > /tmp/cc42f7aq.o: In function `main': > thread-hello.c:(.text+0x58): undefined reference to `pthread_create' You need to do: cc thread-hello2.c -lpthread > I tried "cpp /usr/src/hello.cpp", and got this: > > /home # cpp /usr/src/hello.cpp > # 1 "/usr/src/hello.cpp" > # 1 "" > # 1 "" > # 1 "/usr/src/hello.cpp" > /usr/src/hello.cpp:1:20: error: iostream: No such file or directory Huh. Ok, _that_ should be working. New wrapper has to be getting the search paths wrong. I'll add it to the todo heap. Thanks. > using namespace std; > > int main() > { > cout << "hello world" << endl; > return 0; > } > > I wrote my own hello.c in my home directory, and things worked fine. > > None of this is major stuff - just a slight discrepancy between the image > contents and the README, but I thought I'd report it anyhow. Thanks. There's been a certain amount of bit-rot along the way. Toybox has been eating all my time, and what time I've had for aboriginal has been taken over by the musl switchover. Which is like 80% done: you can build a musl version for most targets by commenting out the UCLIBC_CONFIG stanza in the appropriate target file. (Before release I should add a MUSL=1 thing to configure so you can trigger that without having to edit the target file.) Unfortunately I can't switch over to musl this release because the toolchain isn't honoring -Bsymbolic-functions and that means building anything more complicated than hello world gets confused for reasons I have to go re-read the explanation for every time I try to fix them (ask Rich Felker, I.E. dalias on freenode), and some targets (ala http://landley.net/notes.html#03-07-2014) don't work at all. So yeah: I was debugging the new "find.c" forever (lots tricksy corner cases), and debugging musl forever, and debugging the 3.15 kernel which despite http://lists.landley.net/pipermail/aboriginal-landley.net/2014-July/001402.html doesn't give me a serial console on i586 unless I fix the config thing above... > Thanks for all your great work! > > -- Tim Bird > Senior Software Engineer, Sony Mobile > Architecture Group Chair, CE Workgroup, Linux Foundation I'm glad you're finding it useful. I'm coding as fast as I can... Speaking of which, I'm honestly tempted to apply for http://www.openbsdfoundation.org/gsoc2014.html#systemd since it's something I have to do for toybox _anyway_ and having somebody mentor me with what they actually need the result to _do_ would save a lot of time... (Someday, LFS build update! Honest and truly, it is a thing I mean to do...) Rob 1408049954.0 From rob at landley.net Mon Aug 18 04:28:27 2014 From: rob at landley.net (Rob Landley) Date: Sun, 17 Aug 2014 23:28:27 -0500 Subject: [Aboriginal] /usr/src <-> README mismatch In-Reply-To: References: Message-ID: <53F180EB.2040406@landley.net> On 08/13/2014 06:58 PM, Tim Bird wrote: > Hey Rob, > > I've been playing around with aboriginal, Me too. :) Got my email machine fixed (bad ram), catching up on a week's worth of messages. Don't remember if I already replied to this one... > and I noticed a discrepancy between > the contents of /usr/src (for system-image-armv6l) and the online README. > > The README says you can do: > > cc /usr/src/hello.c > > but there is no hello.c in /usr/src: Fixed in the repository, but there's still some other fallout from adding musl support that I need to fix before I can cut a release. (I haven't fully debugged the musl build stuff yet so I need to cut a release still using uClibc so I don't fall too far behind the kernel releases, but the new infrastructure that can do musl or uClibc introduced a couple uClibc regressions I'm still squashing.) Next release I want to make use of the initmpfs patches I sent upstream and put simple-root-filesystem in initramfs, and then have the init script call a splice-toolchain.sh to add the native-compiler stuff into the $PATH at runtime. (Probably by adding symlinks to the rootfs.) Longer term I'd like to let the native compiler, the writeable /home space, and the build control image all live in network filesystems. That way sh4 would have an easier time getting supported... > (armv6l:1) /home # ls /usr/src > MANIFEST config-linux hello.cpp thread-hello.c > config-busybox config-uClibc host-info thread-hello2.c > > I tried "cc /usr/src/thread-hello.c" and got the following: > > (armv6l:1) /home # cc /usr/src/thread-hello.c > /tmp/cc42f7aq.o: In function `main': > thread-hello.c:(.text+0x58): undefined reference to `pthread_create' You need -lpthread for that. And thread-hello2.c is the one that proves thread infrastructure works, the other one's too simple to actually prove anything. :) > I tried "cpp /usr/src/hello.cpp", and got this: > > /home # cpp /usr/src/hello.cpp > # 1 "/usr/src/hello.cpp" > # 1 "" > # 1 "" > # 1 "/usr/src/hello.cpp" > /usr/src/hello.cpp:1:20: error: iostream: No such file or directory > > using namespace std; > > int main() > { > cout << "hello world" << endl; > return 0; > } Hmmm, the c++ header path isn't set right. Is this the previous release (using the old ccwrap) or the current source control version (using the new ccwrap?) I rewrote this infrastructure recently, and it's entirely possible I broke the parts I haven't managed to test yet. I keep running the lfs-bootstrap.hdc build, finding something wrong, fixing that, rinse repeat. Kinda slow from my netbook. Nice to have the big machine back, even if it's only got half the memory right now. (One of the memory sticks went bad, that's why it was bricked.) > I wrote my own hello.c in my home directory, and things worked fine. > > None of this is major stuff - just a slight discrepancy between the image > contents and the README, but I thought I'd report it anyhow. Thanks. It's very helpful. Rob 1408336107.0