From rob at landley.net Sat Nov 2 20:46:28 2013 From: rob at landley.net (Rob Landley) Date: Sat, 02 Nov 2013 15:46:28 -0500 Subject: [Aboriginal] about the strace-android In-Reply-To: <201310170431.19494.vda.linux@googlemail.com> (from vda.linux@googlemail.com on Wed Oct 16 21:31:19 2013) References: <201310170431.19494.vda.linux@googlemail.com> Message-ID: <1383425188.1974.241@driftwood> On 10/16/2013 09:31:19 PM, Denys Vlasenko wrote: > On Wednesday 02 October 2013 18:03, Xiaoyong Zhou wrote: > > Hi, Denys: > > > > I just forked the strace-android but the project does not seem to > have > > enough documentation. I would like to use it to trace binder ioctl > on > > android and seems that this project did some improvements. > > > > Could you tell me what's the enhancements and how to compile it for > android > > phone (arm)? > > You can compile strace for ARM using a cross-compiler > or a native compiler for ARM. > > For example, Aboriginal Linux provides qemu-runnable filesystem images > with compiler, kernel and other misc stuff, under which you can build > strace. I actually provide statically linked strace binaries too. See: http://landley.net/aboriginal/bin > Please read strace/qemu_multiarch_testing/README. Was there any follow-up on this one? I have the message marked pending but don't see any replies to it? Rob 1383425188.0 From eric at laganowski.net Thu Nov 7 23:41:57 2013 From: eric at laganowski.net (Eric Laganowski) Date: Thu, 07 Nov 2013 18:41:57 -0500 Subject: [Aboriginal] toolchain placement options In-Reply-To: <1382974495.1974.227@driftwood> Message-ID: <649e-527c2580-5-b843220@180413339> An HTML attachment was scrubbed... URL: From alain.toussaint at securivm.ca Sat Nov 9 09:47:15 2013 From: alain.toussaint at securivm.ca (Alain Toussaint) Date: Sat, 9 Nov 2013 04:47:15 -0500 Subject: [Aboriginal] status report llvm on aboriginal Message-ID: <00c401cedd30$ad574730$0805d590$@securivm.ca> Hello, Tonight, I spent a few hours working on trying to compile git and cmake inside a x86_64 root image build from mercurial version of aboriginal but they both fail. For git, I'm not able to compile out support for libiconv (even specifying -without-libiconv does not cut it as it want to include iconv support upon enabling the switch). For cmake, I think it work on LightCube-OS because lightcube include libstdc++ while aboriginal uses uClibc++ (and I've thought at working the requirement of including libc++ support in aboriginal but I fear this may be a chicken-eggs problem). I'll continue hacking llvm/clang on it (during the rest of the night) but will use tarballs as opposed to git. Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.toussaint at securivm.ca Sat Nov 9 11:34:18 2013 From: alain.toussaint at securivm.ca (Alain Toussaint) Date: Sat, 9 Nov 2013 06:34:18 -0500 Subject: [Aboriginal] llvm status report Message-ID: <00e401cedd3f$a120c2c0$e3624840$@securivm.ca> Hello, Llvm fail to compile the first file it encounter; one of the complaint: /usr/bin/../c++/include/limits:24:2: warning: #warning limits header is nowhere complete or accurate Full report here: (x86_64:1) /home/llvm-3.3.src # make llvm[0]: Constructing LLVMBuild project information. make[1]: Entering directory `/home/llvm-3.3.src/lib/Support' llvm[1]: Compiling APFloat.cpp for Release+Asserts build In file included from /home/llvm-3.3.src/include/llvm/Support/SwapByteOrder.h:20, from /home/llvm-3.3.src/include/llvm/Support/MathExtras.h:17, from /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:19, from /home/llvm-3.3.src/include/llvm/ADT/ArrayRef.h:14, from /home/llvm-3.3.src/include/llvm/ADT/APInt.h:18, from /home/llvm-3.3.src/include/llvm/ADT/APFloat.h:104, from APFloat.cpp:15: /usr/bin/../c++/include/limits:24:2: warning: #warning limits header is nowhere complete or accurate distcc[26614] ERROR: compile APFloat.cpp on 10.0.2.2:21178/1 failed distcc[26614] (dcc_build_somewhere) Warning: remote compilation of 'APFloat.cpp' failed, retrying locally distcc[26614] Warning: failed to distribute APFloat.cpp to 10.0.2.2:21178/1, running locally instead In file included from /home/llvm-3.3.src/include/llvm/Support/SwapByteOrder.h:20, from /home/llvm-3.3.src/include/llvm/Support/MathExtras.h:17, from /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:19, from /home/llvm-3.3.src/include/llvm/ADT/ArrayRef.h:14, from /home/llvm-3.3.src/include/llvm/ADT/APInt.h:18, from /home/llvm-3.3.src/include/llvm/ADT/APFloat.h:104, from APFloat.cpp:15: /usr/bin/../c++/include/limits:24:2: warning: #warning limits header is nowhere complete or accurate In file included from /home/llvm-3.3.src/include/llvm/ADT/ArrayRef.h:14, from /home/llvm-3.3.src/include/llvm/ADT/APInt.h:18, from /home/llvm-3.3.src/include/llvm/ADT/APFloat.h:104, from APFloat.cpp:15: /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In static member function 'static void llvm::SmallVectorTemplateBase::uninitialized_move(It1, It1, It2)': /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:218: error: 'uninitialized_copy' is not a member of 'std' /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In static member function 'static void llvm::SmallVectorTemplateBase::uninitialized_copy(It1, It1, It2)': /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:226: error: 'uninitialized_copy' is not a member of 'std' /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In static member function 'static void llvm::SmallVectorTemplateBase::uninitialized_copy(It1, It1, It2)': /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:331: error: 'uninitialized_copy' is not a member of 'std' /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In member function 'void llvm::SmallVectorImpl::resize(unsigned int)': /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:408: error: 'uninitialized_fill' is not a member of 'std' /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In member function 'void llvm::SmallVectorImpl::resize(unsigned int, const T&)': /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:420: error: 'uninitialized_fill' is not a member of 'std' /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In member function 'void llvm::SmallVectorImpl::append(in_iter, in_iter)': /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:454: error: 'uninitialized_copy' is not a member of 'std' /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In member function 'void llvm::SmallVectorImpl::append(typename llvm::SmallVectorTemplateBase::value>::size_type, const T&)': /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:466: error: 'uninitialized_fill_n' is not a member of 'std' /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In member function 'void llvm::SmallVectorImpl::assign(unsigned int, const T&)': /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:475: error: 'uninitialized_fill' is not a member of 'std' /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In member function 'typename llvm::SmallVectorTemplateBase::value>::iterator llvm::SmallVectorImpl::insert(typename llvm::SmallVectorTemplateBase::value>::iterator, typename llvm::SmallVectorTemplateBase::value>::size_type, const T&)': /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:614: error: 'uninitialized_fill_n' is not a member of 'std' distcc[26614] ERROR: compile APFloat.cpp on localhost failed make[1]: *** [/home/llvm-3.3.src/lib/Support/Release+Asserts/APFloat.o] Error 1 make[1]: Leaving directory `/home/llvm-3.3.src/lib/Support' make: *** [all] Error 1 May I offer to work on implementing pathscale's libcxxrt (and by the same token, musl-libc) in aboriginal build script? I tried to find every places where uClibc(++) are involved but there's many place where I need to hack on and I don't know where to start. Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From lineage2005 at gmail.com Sat Nov 9 15:31:01 2013 From: lineage2005 at gmail.com (Milo Hoffmann) Date: Sat, 9 Nov 2013 08:31:01 -0700 Subject: [Aboriginal] [PATCH] CONFIG_NET_CORE=y required for VIRTIO_NET to build Message-ID: Hello list, Please review the below patch, generated with the diff provided in Aboriginal, for inclusion into Aboriginal. I updated only the i686-virtio target as it appears to be the most KVM-centric target and that is where I spend most of my time. Feel free to put it into baseconfig instead, if more appropriate. I'm not real sure what caused CONFIG_NET_CORE to go missing in 1.2.5 with the i686-virtio target. I _think_ a change in the kernel Makefiles/Kconfig is the root cause but haven't dug in that deep yet. Background: Aboriginal release 1.2.4.1 built the VIRTIO_NET driver without issue but release 1.2.5 did not. This can be confirmed by the absence of VIRTIO_NET and "CONFIG_NET_CORE is not set" in the /proc/config.gz of a clean 1.2.5 build. --- --- aboriginal-1.2.5_pure/sources/targets/i686-virtio/settings +++ aboriginal-1.2.5/sources/targets/i686-virtio/settings @@ -12,6 +12,7 @@ LINUX_CONFIG=" CONFIG_MPENTIUMII=y CONFIG_ACPI=y +CONFIG_NET_CORE=y # VIRTIO_CONSOLE not used yet CONFIG_SERIAL_8250=y --- Milo 1384011061.0 From rob at landley.net Sat Nov 23 23:52:10 2013 From: rob at landley.net (Rob Landley) Date: Sat, 23 Nov 2013 17:52:10 -0600 Subject: [Aboriginal] New release using 3.12 kernel. Message-ID: <1385250730.1974.281@driftwood> It's up on the website. I'm still something like 3 weeks behind on my email (grinding away at that now). Rob 1385250730.0 From rob at landley.net Wed Nov 27 22:51:02 2013 From: rob at landley.net (Rob Landley) Date: Wed, 27 Nov 2013 16:51:02 -0600 Subject: [Aboriginal] toolchain placement options In-Reply-To: <649e-527c2580-5-b843220@180413339> (from eric@laganowski.net on Thu Nov 7 17:41:57 2013) Message-ID: <1385592662.1974.286@driftwood> On 11/07/2013 05:41:57 PM, Eric Laganowski wrote: > > I'm trying to convert aboriginal over to use musl-libc > > > Natively, if you want to use a different libc the most obvious > approach > > is to build a chroot that uses it. Start by installing your new > > toolchain in a directory under /home in the system iamge (which > > dev-environment.sh attaches a 2 gigabyte hdb.img ext3 image to by > > default, so it' s writeable and potentially persistent), then use > that > > toolchain to build more stuff. > > I guess I can more or less follow the LFS approach in native stage, > though > I will need to satisfy LFS "host system requirements" by building > Perl, > Texinfo, etc and then start building what LFS calls "Temporary > System". I pointed you at http://landley.net/aboriginal/control-images/lfs-bootstrap.hdc right? I've already got an automated thing that does this, and I usually upload the resulting images when I do a release, somewhere under: http://landley.net/aboriginal/downloads/binaries/extras > The thing is, however, is that this diminishes Aboriginal's value as a > _build_ > system, as I can launch any target-specific distro under QEMU, > possibly > with all pre-requisites already there and proceed with LFS stages in > the > same or possibly even more convenient fashion. The point of aboriginal linux is that it creates from scratch the simplest native build environment for an arbitrary target, in a reproducible way. It then provides some infrastructure to perform automated native builds within that, either on real hardware or under qemu. One such piece of infrastructure is the lfs-bootstrap image, which I need to update to 7.4. > I guess if you are not planning to develop Aboriginal in direction of > a > flexible build system this is fine by me. I'm not turning it into a full-fledged distro. what I want to do is create bootstrap images for distros, so you can do a debian-boostrap and gentoo-bootstrap and fedora-bootstrap and so on that create a chroot within which their build tools will run to add more packages, building them from source and loading them into their repository on whatever the host happens to be. So if you want to create "slackware on sh4", you can do so. Alas, that turns out to be a big job (gentoo assumes it's building under gentoo, _and_ every ebuild file in portage is annotated with the complete list of every target it's allowed to run on, so adding a new target to the portage tree requires touching just about every ebuild file in the tree because they weren't THINKING...) It's a todo item, but switching everything over to use toybox and musl and getting android self-hosting are higher priority todo items. > Please let me know if I am missing something. > > What I attempted to accomplish was to have Aboriginal provide me with > a > native toolchain that can build the entire (possibly > embedded-targeting > ) > system where I can use the C library of my choosing, or at least not > to > depend on cross-compiled native C library. Yes, that's definitely a goal of the project. > I had some ideas on how to > provide for packaging support (rpm or opkg) using AUFS (for which I > ship > custom kernel to Aboriginal), but at this point I am stuck with the > (almost) > chicken and egg issue, and my cross-compilation/toolchain experience > is > not > enough to overcome them. I'm working on getting musl working. Once I've done that I should go back and do "build a uClibc chroot under musl" and "build a glibc chroot under musl" bootstrap.hdc files. > By the way, is there a way to checkout the most recent stable > Aboriginal > revision that still supports the /tools hierarchy? It would be something like 3 years old. Look at /sbin/setup-chroot instead. (In the source it's sources/root-filesystem/sbin/setup-chroot I think.) Rob 1385592662.0 From patrick at gentoo.org Thu Nov 28 00:21:14 2013 From: patrick at gentoo.org (Patrick Lauer) Date: Thu, 28 Nov 2013 08:21:14 +0800 Subject: [Aboriginal] toolchain placement options In-Reply-To: <1385592662.1974.286@driftwood> References: <1385592662.1974.286@driftwood> Message-ID: <52968C7A.7010305@gentoo.org> On 11/28/2013 06:51 AM, Rob Landley wrote: >> I guess if you are not planning to develop Aboriginal in direction of a >> flexible build system this is fine by me. > > I'm not turning it into a full-fledged distro. what I want to do is > create bootstrap images for distros, so you can do a debian-boostrap and > gentoo-bootstrap and fedora-bootstrap and so on that create a chroot > within which their build tools will run to add more packages, building > them from source and loading them into their repository on whatever the > host happens to be. So if you want to create "slackware on sh4", you can > do so. > > Alas, that turns out to be a big job (gentoo assumes it's building under > gentoo, _and_ every ebuild file in portage is annotated with the > complete list of every target it's allowed to run on, so adding a new > target to the portage tree requires touching just about every ebuild > file in the tree because they weren't THINKING...) Let me just disagree with you ;) There's a very reasonable assumption that things will fail on a new architecture, so it makes more sense to whitelist things when they have been tested, patched and beaten into submission. Blacklisting things is not good when you want everything to build, because it's hard to get enough test coverage (build everything on HPPA? You funny person ...) and to keep the blacklist updated for new versions (Who would have guessed that Java/Icedtea still doesn't build on SPARC?) (On a sidenote, if you are in a I-Don't-Care mode you can just tell portage to accept anything - or that anything that works on x86 should be ok too. But that's Not A Good Idea :) ) And luckily your "Gentoo needs Gentoo" claim has been undermined over the years, first by Gentoo Prefix (which even works on win32 and other mad platforms) and lately by RAP ("RAP ain't Prefix") which started as an experiment on Android ( http://wiki.gentoo.org/wiki/Project:Android/build ) Have fun, Patrick 1385598074.0 From rob at landley.net Fri Nov 29 02:59:15 2013 From: rob at landley.net (Rob Landley) Date: Thu, 28 Nov 2013 20:59:15 -0600 Subject: [Aboriginal] [PATCH] CONFIG_NET_CORE=y required for VIRTIO_NET to build In-Reply-To: (from lineage2005@gmail.com on Sat Nov 9 09:31:01 2013) Message-ID: <1385693955.1974.292@driftwood> On 11/09/2013 09:31:01 AM, Milo Hoffmann wrote: > Hello list, > > Please review the below patch, generated with the diff provided in > Aboriginal, for inclusion into Aboriginal. I updated only the > i686-virtio target as it appears to be the most KVM-centric target and > that is where I spend most of my time. Feel free to put it into > baseconfig instead, if more appropriate. > > I'm not real sure what caused CONFIG_NET_CORE to go missing in 1.2.5 > with the i686-virtio target. I _think_ a change in the kernel > Makefiles/Kconfig is the root cause but haven't dug in that deep yet. Another bug is that the 9p guys broke the filesystem by unconditionally defaulting to virtio even if you give it an ipv4 address. There's code to detect type but it's called _after_ the unconditional default to virtio. It was kernel commit 535bcd3c4e8d09a62a89b2f1f3b3a80e1b3fce4b and as far as I'm concerned 9p is completely broken until that's reverted. I'll probably do a local patch to revert it next time around. I've made a note of this, but until I get the basic problem with 9p fixed I'm unlikely to test virto. Upstream did something DEEPLY STUPID. Thanks for the heads up, Rob 1385693955.0 From rob at landley.net Thu Nov 28 04:00:32 2013 From: rob at landley.net (Rob Landley) Date: Wed, 27 Nov 2013 22:00:32 -0600 Subject: [Aboriginal] llvm status report In-Reply-To: <00e401cedd3f$a120c2c0$e3624840$@securivm.ca> (from alain.toussaint@securivm.ca on Sat Nov 9 05:34:18 2013) Message-ID: <1385611232.1974.290@driftwood> On 11/09/2013 05:34:18 AM, Alain Toussaint wrote: > Hello, > > Llvm fail to compile the first file it encounter; one of the > complaint: > > /usr/bin/../c++/include/limits:24:2: warning: #warning limits header > is > nowhere complete or accurate That's an english result of a test. I need to see the test... (I'm also far less up to speed on c++ than I am on C. Mostly I've been building a toolchain with libstdc++ as part of the LFS bootstrap and using that if something really complained...) > /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h: In static member > function > 'static void llvm::SmallVectorTemplateBase isPodLike>::uninitialized_move(It1, It1, It2)': > > /home/llvm-3.3.src/include/llvm/ADT/SmallVector.h:218: error: > 'uninitialized_copy' is not a member of 'std' So... what standard says these should be there? > May I offer to work on implementing pathscale's libcxxrt (and by the > same > token, musl-libc) in aboriginal build script? By all means, yes. I expect to unwrap ellcc.org and implement the components one by one. I'm abotu halfway through implementing musl support, which is mostly a matter of rewriting my ccwrap.c file. (The musl wrapper generates a spec file at compile time, but I need something that dynamically determines where the binary lives and and generates paths relative to that on the fly...) > I tried to find every places > where uClibc(++) are involved but there's many place where I need to > hack on > and I don't know where to start. Replacing it makes sense. Rob 1385611232.0 From rob at landley.net Thu Nov 28 03:53:41 2013 From: rob at landley.net (Rob Landley) Date: Wed, 27 Nov 2013 21:53:41 -0600 Subject: [Aboriginal] status report llvm on aboriginal In-Reply-To: <00c401cedd30$ad574730$0805d590$@securivm.ca> (from alain.toussaint@securivm.ca on Sat Nov 9 03:47:15 2013) Message-ID: <1385610821.1974.289@driftwood> On 11/09/2013 03:47:15 AM, Alain Toussaint wrote: > Hello, Catching up on email! Slowly but... slowly. > Tonight, I spent a few hours working on trying to compile git and > cmake > inside a x86_64 root image build from mercurial version of aboriginal > but > they both fail. I've built git under aboriginal before... http://landley.net/notes-2011.html#26-10-2011 (And the git guys later said that ./configure is just a wrapper for windows builds, and I should just supply the make variables for all my options. Either way, worked for me.) Haven't tried cmake. I vaguely recall that's python? I've bulit python before, back when I was trying to build gentoo... http://landley.net/hg/control-images/file/tip/images/gentoo-bootstrap Looks like it's just ./configure; make; make install and it's done after zlib and ncurses (the mnt/package-list file controls the order of builds and the mnt/build directory contains each package's build script...) Neither are hugely current, but they worked at one point... > For git, I'm not able to compile out support for libiconv > (even specifying -without-libiconv does not cut it as it want to > include > iconv support upon enabling the switch). Which is why I had to bypass the ./configure and specify that variable by hand on the make command line. > For cmake, I think it work on > LightCube-OS because lightcube include libstdc++ while aboriginal uses > uClibc++ (and I've thought at working the requirement of including > libc++ > support in aboriginal but I fear this may be a chicken-eggs problem). I very, very vaguely remember a mention of a cmake bug with libuClibc++. I've been meaning to try llvm's libc++ at some point. Needing it as a chicken and egg problem sounds unhappy, though... The problem with libstdc++ is that it's part of the gcc source. It's not a standalone package. And it does NOT like to cross-compile, nor is it really happy building against anything except glibc. (I've fought against it before. Not recently, but it was annoying at the time...) > I'll continue hacking llvm/clang on it (during the rest of the night) > but > will use tarballs as opposed to git. What do you need cmake for? (The llvm build?) Rob 1385610821.0 From alain.toussaint at securivm.ca Fri Nov 29 18:02:56 2013 From: alain.toussaint at securivm.ca (Alain Toussaint) Date: Fri, 29 Nov 2013 13:02:56 -0500 Subject: [Aboriginal] status report llvm on aboriginal In-Reply-To: <1385610821.1974.289@driftwood> References: <1385610821.1974.289@driftwood> Message-ID: <5E7C5789-E4F7-4FB7-92A6-8CCE3E05EB5D@securivm.ca> > What do you need cmake for? (The llvm build?) Yup. Alain 1385748176.0 From samuel at sholland.net Sat Nov 30 18:37:31 2013 From: samuel at sholland.net (Samuel Holland) Date: Sat, 30 Nov 2013 12:37:31 -0600 Subject: [Aboriginal] status report llvm on aboriginal In-Reply-To: <1385610821.1974.289@driftwood> References: <1385610821.1974.289@driftwood> Message-ID: <3e0b6a9a-0801-4e15-b40f-574b88bab36b@email.android.com> Rob Landley wrote: >The problem with libstdc++ is that it's part of the gcc source. It's >not a standalone package. And it does NOT like to cross-compile, nor is >it really happy building against anything except glibc. (I've fought >against it before. Not recently, but it was annoying at the time...) > >> I'll continue hacking llvm/clang on it (during the rest of the night) > >> but >> will use tarballs as opposed to git. > >What do you need cmake for? (The llvm build?) > >Rob >_______________________________________________ >Aboriginal mailing list >Aboriginal at lists.landley.net >http://lists.landley.net/listinfo.cgi/aboriginal-landley.net Of course I realize you don't like the new GPL3 gcc versions, but in 4.8+ (and any future 4.7 releases), libstdc++ can be built independently. The latest LFS book does it gcc->libc->libstdc++ It also builds and works fine against the latest musl release, both cross-compiled and pseudo-natively (--build). I've been automating a static-musl-LFS bootstrap using pacman (https://github.com/smaeul/starch), and the only issue so far has been gcc autohell. cmake is required for libcxxrt/libc++. LLVM itself works with autotools. cmake can also be bootstrapped with autotools. 1385836651.0