From rob at landley.net Wed Jul 3 07:06:19 2013 From: rob at landley.net (Rob Landley) Date: Wed, 03 Jul 2013 02:06:19 -0500 Subject: [Aboriginal] package building problems In-Reply-To: <51CE35E9.2040901@lamiaworks.com.au> (from scsijon@lamiaworks.com.au on Fri Jun 28 20:18:33 2013) Message-ID: <1372835179.5019.18@driftwood> On 06/28/2013 08:18:33 PM, scsijon wrote: > with aboriginal-84bd3248fad8: > > We have had a problem or two attempting to build a few packages, it > was > found that adding "UCLIBC_HAS_GETPT=y" to sources/baseconfig-uClibc > has > solved some of them such as rxvt. Added it. > On the other hand we seem to have a few expected /include '.h' files > missing that are normally used for building with after building the > new aboriginal to 'play with'. Such as libc.h, sys/byteorder.h, > sys/strredir.h, sys/sockio.h, sys/sockio.h, sys/stropts.h. I was > wondering if this is deliberate or just not used. It's not deliberate. I'm not seeing "byteorder.h" in uClibc. (There's an asm/byteorder.h in the kernel headers...) cd uClibc $ find . -name byteorder.h $ find . -type f | xargs grep byteorder ./libc/inet/ntohl.c:#error "You seem to have an unsupported byteorder" You might want to look at musl-libc.org instead, I plan to switch to that in the next release or two. (It's much more actively maintained, and BSD licensed.) Rob 1372835179.0 From scsijon at lamiaworks.com.au Mon Jul 8 02:43:08 2013 From: scsijon at lamiaworks.com.au (scsijon) Date: Mon, 08 Jul 2013 12:43:08 +1000 Subject: [Aboriginal] Toybox post from lamiaworks>aboriginal's list In-Reply-To: <1373126847.27613.4@driftwood> References: <1373126847.27613.4@driftwood> Message-ID: <51DA273C.2090701@lamiaworks.com.au> On 07/07/2013 02:07 AM, Rob Landley wrote: > On 07/03/2013 06:49:35 AM, lamiaworks wrote: > >> I'm also going to have a look at buildroot and see if it will 'do' the >> frontend >> 'stuff' before running aboriginal's ./build.sh. This would be an >> alternative to >> our woof2 puppy build system. > > I've been meaningto try to get buildroot compiling under aboriginal for > ages. I want to bootstrap all sorts of distros (fedora, debian, gentoo, > etc) natively under an arbitrary host architecture, to eliminate the > need for cross compiling. Get a minimal development environment for the > new target, compile more stuff on real hardware or under an emulator, > don't _try_ to cross compile 200 packages because it's horrible. > >> Then us/you could supply anyone with a fully working stand-alone basic >> ?cross-compiling system. Now that would put you out there! > > The project's motto is "we cross compile so you don't have to". The > about.html page does (eventually) explain what that means. :) > > Rob Had a problem with buildroot and missing headers, a query back to Peter K got the response: > scsijon> Any chance that buildroot may have a 'switch' to make the development > scsijon> files (compiler, header files, etc.) appear in the target. > > We used to have that (BR2_HAVE_DEVFILES), but it has been deprecated for > a while and has recently been completely removed. And I commented back: -- I think that this then maybe a break to the GPL, by compiling but not having the dev files available, or are you working under a restricted GPL. -- Means for me that I can't add or work on anything already in the built system without a lot of additional work, so i'm not going to use them, I shall do some preliminary work on another idea to use as a first stage and use aboriginal as the second stage. This should really be in aboriginal's threads so i'm moving it. regards scsijon 1373251388.0 From rob at landley.net Mon Jul 8 07:26:49 2013 From: rob at landley.net (Rob Landley) Date: Mon, 08 Jul 2013 02:26:49 -0500 Subject: [Aboriginal] 1.2.4 is out. Message-ID: <1373268409.27613.15@driftwood> And caught up with the 3.10 kernel, with everything (except m68k and mips64 and arm big endian) working under qemu 1.5.1. Release notes on the website. I go to bed now. Rob 1373268409.0 From rob at landley.net Tue Jul 9 01:59:00 2013 From: rob at landley.net (Rob Landley) Date: Mon, 08 Jul 2013 20:59:00 -0500 Subject: [Aboriginal] Brown paper bag bug, 1.2.4.1 release. Message-ID: <1373335140.27613.19@driftwood> Remember, just because you report a bug to linux-kernel a month and change before they ship the final version doesn't mean that anyone will notice, let alone fix it. http://lkml.indiana.edu/hypermail/linux/kernel/1305.2/01452.html (Gah. Didn't check in a file. hg commit sources/patches/* doesn't get files you never did an "hg add" on, and the bug never did get fixed upstream.) The binaries are still good, they just didn't quite match the source tarball due to a diff between repo state and working directory. And I got the dropbear and strace binaries up (now including 32 bit sparc). The old 1.2.4 tarball got moved to downloads/old. I've been cutting corners because my rebuilds are so slow on this netbook. Finally broke down and ordered an i5 laptop. Should get here in a few days... Rob 1373335140.0 From scsijon at lamiaworks.com.au Tue Jul 9 23:32:08 2013 From: scsijon at lamiaworks.com.au (scsijon) Date: Wed, 10 Jul 2013 09:32:08 +1000 Subject: [Aboriginal] multi-build option request Message-ID: <51DC9D78.3050604@lamiaworks.com.au> Any chance of adding an 'all' to the './build.sh' cross compiler line, and have it build the lot. Reason is to ensure all that is built are EXACTLY the same version set. And yes, i've already managed to stuff-up using two different 'current' tarballs i'd downloaded and built against for two different platforms (-;! 1373412728.0 From rob at landley.net Wed Jul 10 01:21:08 2013 From: rob at landley.net (Rob Landley) Date: Tue, 09 Jul 2013 20:21:08 -0500 Subject: [Aboriginal] Alpha! Message-ID: <1373419268.27613.33@driftwood> Ooh, this implies that qemu-system-alpha actually works these days: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01356.html (I built alpha images way way back, but dropped it because qemu only did application emulation, not the ring 0 stuff. Here's hoping it's _not_ nommu, because I never did bother with that...) Rob 1373419268.0 From rob at landley.net Wed Jul 10 01:40:42 2013 From: rob at landley.net (Rob Landley) Date: Tue, 09 Jul 2013 20:40:42 -0500 Subject: [Aboriginal] multi-build option request In-Reply-To: <51DC9D78.3050604@lamiaworks.com.au> (from scsijon@lamiaworks.com.au on Tue Jul 9 18:32:08 2013) Message-ID: <1373420442.27613.35@driftwood> On 07/09/2013 06:32:08 PM, scsijon wrote: > Any chance of adding an 'all' to the './build.sh' cross compiler > line, > and have it build the lot. That's what "more/buildall.sh" is for (and more/buildall-native.sh to do native builds). The logs wind up in build/logs, and it does the full logs with more/record-commands.sh so there's a ton of forensic data on the build. (Some releases I post said logs. This time the build was a bit chopped up for the logs to be meaningful, which kinda turned around and bit me... :) You can export FORK=1 for both (FORK=1 more/buildall.sh) to launch all the builds in parallel, it'll check how much ram you've got and how many CPUS and try not to overwhelm the server too badly, but it can't can't do less than CPUS=1 for each parallel build. > Reason is to ensure all that is built are EXACTLY the same version > set. > And yes, i've already managed to stuff-up using two different > 'current' > tarballs i'd downloaded and built against for two different platforms > (-;! I've been poking at aboriginal linux on and off since either 1999 or 2002 (depending on how you want to look at it, someday I should finish http://landley.net/aboriginal/history.html), and the 3-ish relaunches were each because I'd figured how a SIMPLER way to do it, so I threw out what I had and started over. The current design does what I set out to do, and it's organized into a series of orthogonal layers each of which may be skipped or replaced. (So ./download.sh doesn't have to be what populates the "packages" directory, if you don't run host-tools.sh it'll use the host $PATH and you have to set the host system up VERY carefully so this doesn't break, you can use a different simple-cross-compiler.sh if you like (just mkdir build/simple-cross-compiler/bin and make the appropriate symlinks so it finds the right names at the exptected $PATH), build.sh will skip cross-compiler.sh by default unless you set an environment variable asking for it (which buildall.sh does), and so on. However, it's at pretty much complexity saturation level. The package cache speeds up the build tremendously (especially multiple parallel builds) but it's fiddly and complicated and half the FAQ is devoted to explaining how it works. (It's designed so you can completely IGNORE it and treat "setupfor" like it's extracting the tarball each time, but...) All the files at the top level are build stages. That means if I want to implement something that's NOT a build stage, I have to put it in a subdirectory, where nobody notices it. "more" is the main subdirectory for doing this. Please let me know how I should document this in a way that doesn't take hours to read. I've tried many times over the years. I suppose I should try again... Rob 1373420442.0 From lamiaworks at skymesh.com.au Mon Jul 1 22:38:23 2013 From: lamiaworks at skymesh.com.au (lamiaworks) Date: Tue, 02 Jul 2013 08:38:23 +1000 Subject: [Aboriginal] Aboriginal missing headers? In-Reply-To: References: Message-ID: <51D204DF.1090001@skymesh.com.au> > Message: 1 > Date: Sat, 29 Jun 2013 16:59:30 -0700 > From: Isaac > To: aboriginal at lists.landley.net > Subject: Re: [Aboriginal] missing headers? > Message-ID: <20130629235930.GA1368 at newbook> > Content-Type: text/plain; charset=us-ascii > > On Sat, Jun 29, 2013 at 01:31:25PM -0700, aboriginal-request at lists.landley.net wrote: >> From: scsijon >> >> We have had a problem or two attempting to build a few packages, it was >> found that adding "UCLIBC_HAS_GETPT=y" to sources/baseconfig-uClibc has >> solved some of them such as rxvt. >> >> On the other hand we seem to have a few expected /include '.h' files >> missing that are normally used for building with after building the new >> aboriginal to 'play with'. Such as libc.h, sys/byteorder.h, >> sys/strredir.h, sys/sockio.h, sys/sockio.h, sys/stropts.h. I was >> wondering if this is deliberate or just not used. > > Ubuntu Lucid, all headers installed: > $ dlocate /libc.h > $ dlocate byteorder.h|grep sys/ > $ dlocate sys/strredir.h > $ dlocate strredir.h > $ dlocate sys/sockio.h > $ dlocate sockio.h > $ dlocate sys/stropts.h > libc6-dev: /usr/include/sys/stropts.h > > In other wordds, the vast majority are not present on a standard Linux system. > And contains only this: > > #include > >> thanks >> scsijon > > ------------------------------ Thanks Isaac, but using Aboriginal's README which states for root-filesystem-$ARCH.tar.bz2: ---- Combination of simple-root-filesystem and native-compiler into a single filesystem. This is what the system images use for their minimal native development environment root filesystem. ---- I did expect any DEVELOPMENT environment to have all it's internal packages header files included, even a minimal one. and the same against "system-image-$ARCH.tar.bz2", which starts: ---- Prepackaged bootable system images image for each target, which boot and run under QEMU and allow you to natively compile additional packages within the emulated development environment. ---- and I thought and expected, would have needed these header files to be able to deal with the additional packages. regards scsijon 1372718303.0 From idunham at lavabit.com Wed Jul 10 22:11:42 2013 From: idunham at lavabit.com (Isaac) Date: Wed, 10 Jul 2013 15:11:42 -0700 Subject: [Aboriginal] Aboriginal missing headers? In-Reply-To: References: Message-ID: <20130710221142.GA8795@newbook> On Wed, Jul 10, 2013 at 01:30:13PM -0700, aboriginal-request at lists.landley.net wrote: > Send Aboriginal mailing list submissions to > aboriginal at lists.landley.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net > or, via email, send a message with subject or body 'help' to > aboriginal-request at lists.landley.net > > You can reach the person managing the list at > aboriginal-owner at lists.landley.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Aboriginal digest..." > > > Today's Topics: > > 1. multi-build option request (scsijon) > 2. Alpha! (Rob Landley) > 3. Re: multi-build option request (Rob Landley) > 4. Re: Aboriginal missing headers? (lamiaworks) > Message-ID: <51D204DF.1090001 at skymesh.com.au> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Message: 1 > > Date: Sat, 29 Jun 2013 16:59:30 -0700 > > From: Isaac > > To: aboriginal at lists.landley.net > > Subject: Re: [Aboriginal] missing headers? > > Message-ID: <20130629235930.GA1368 at newbook> > > Content-Type: text/plain; charset=us-ascii > > > > On Sat, Jun 29, 2013 at 01:31:25PM -0700, aboriginal-request at lists.landley.net wrote: > >> From: scsijon > >> > >> We have had a problem or two attempting to build a few packages, it was > >> found that adding "UCLIBC_HAS_GETPT=y" to sources/baseconfig-uClibc has > >> solved some of them such as rxvt. > >> > >> On the other hand we seem to have a few expected /include '.h' files > >> missing that are normally used for building with after building the new > >> aboriginal to 'play with'. Such as libc.h, sys/byteorder.h, > >> sys/strredir.h, sys/sockio.h, sys/sockio.h, sys/stropts.h. I was > >> wondering if this is deliberate or just not used. > > > > Ubuntu Lucid, all headers installed: > > $ dlocate /libc.h > > $ dlocate byteorder.h|grep sys/ > > $ dlocate sys/strredir.h > > $ dlocate strredir.h > > $ dlocate sys/sockio.h > > $ dlocate sockio.h > > $ dlocate sys/stropts.h > > libc6-dev: /usr/include/sys/stropts.h > > > > In other wordds, the vast majority are not present on a standard Linux system. > > And contains only this: > > > > #include > > Thanks Isaac, but using Aboriginal's README which states for > root-filesystem-$ARCH.tar.bz2: > ---- > Combination of simple-root-filesystem and native-compiler into a > single filesystem. This is what the system images use for their minimal > native development environment root filesystem. > ---- > I did expect any DEVELOPMENT environment to have all it's internal > packages header files included, even a minimal one. > > and the same against "system-image-$ARCH.tar.bz2", which starts: > ---- > Prepackaged bootable system images image for each target, which boot > and run under QEMU and allow you to natively compile additional packages > within the emulated development environment. > ---- > and I thought and expected, would have needed these header files to be > able to deal with the additional packages. What I am saying is that you are probably wrong; these are not needed "to be able to deal with the additional packages." Any package that does require these will FTBFS on >90% of Linux development systems. The system I'm checking on is Ubuntu with the main development packages installed (libc-dev; X, Mesa, motif, gtk1.2 and 2 headers, tons of C++ junk, xulrunner-dev...) . I've built quite a few packages on here; my main source directory has about 3.5 GB in it. (Still not sure how I accumulated that much.) > regards > scsijon HTH, Isaac Dunham 1373494302.0 From rob at landley.net Fri Jul 12 05:52:10 2013 From: rob at landley.net (Rob Landley) Date: Fri, 12 Jul 2013 00:52:10 -0500 Subject: [Aboriginal] Aboriginal missing headers? In-Reply-To: <51D204DF.1090001@skymesh.com.au> (from lamiaworks@skymesh.com.au on Mon Jul 1 17:38:23 2013) Message-ID: <1373608330.27613.53@driftwood> On 07/01/2013 05:38:23 PM, lamiaworks wrote: >> Message: 1 >> Date: Sat, 29 Jun 2013 16:59:30 -0700 >> From: Isaac >> To: aboriginal at lists.landley.net >> Subject: Re: [Aboriginal] missing headers? >> Message-ID: <20130629235930.GA1368 at newbook> >> Content-Type: text/plain; charset=us-ascii >> >> On Sat, Jun 29, 2013 at 01:31:25PM -0700, >> aboriginal-request at lists.landley.net wrote: >>> From: scsijon >>> >>> We have had a problem or two attempting to build a few packages, it >>> was >>> found that adding "UCLIBC_HAS_GETPT=y" to sources/baseconfig-uClibc >>> has >>> solved some of them such as rxvt. >>> >>> On the other hand we seem to have a few expected /include '.h' files >>> missing that are normally used for building with after building the >>> new >>> aboriginal to 'play with'. Such as libc.h, sys/byteorder.h, >>> sys/strredir.h, sys/sockio.h, sys/sockio.h, sys/stropts.h. I was >>> wondering if this is deliberate or just not used. >> >> Ubuntu Lucid, all headers installed: >> $ dlocate /libc.h >> $ dlocate byteorder.h|grep sys/ >> $ dlocate sys/strredir.h >> $ dlocate strredir.h >> $ dlocate sys/sockio.h >> $ dlocate sockio.h >> $ dlocate sys/stropts.h >> libc6-dev: /usr/include/sys/stropts.h >> >> In other wordds, the vast majority are not present on a standard >> Linux system. >> And contains only this: >> >> #include >> >>> thanks >>> scsijon >> >> ------------------------------ > > Thanks Isaac, but using Aboriginal's README which states for > root-filesystem-$ARCH.tar.bz2: > ---- > Combination of simple-root-filesystem and native-compiler into a > single filesystem. This is what the system images use for their > minimal native development environment root filesystem. > ---- > I did expect any DEVELOPMENT environment to have all it's internal > packages header files included, even a minimal one. uClibc does not implement this header. Ubuntu also does not contain this header. I have no idea what you mean by "all its internal packages header files included", and I have no idea where you got the idea that a minimal development environment would contain things that a full distro development environment does not. > and the same against "system-image-$ARCH.tar.bz2", which starts: > ---- > Prepackaged bootable system images image for each target, which > boot and run under QEMU and allow you to natively compile additional > packages within the emulated development environment. > ---- > and I thought and expected, would have needed these header files to be > able to deal with the additional packages. What additional packages? I've built around 100 packages under aboriginal (all of linux from scrach about 1/3 of beyond linux from scratch, plus various other things like dropbear and strace). Nothing I encountered ever needed these headers. (Many things required other prerequisite packages to be built and installed before they would build and install, but that's just a question of adding packages in the right order.) You seem to have very specific needs, which even Ubuntu doesn't fulfill, and I'm sorry the Aboriginal Linux project is not of use to you. I've added stuff before (see the recent commit backporting posix_spawn(), for example), but you can't seem to point to a development environment that _does_ include these headers, you haven't mentioned what packages are failing to compile... You just "expect" them. Not much to go on there. Rob 1373608330.0