From carbrevi at gmail.com Mon Jun 16 21:18:47 2014 From: carbrevi at gmail.com (Carlos Breviglieri) Date: Mon, 16 Jun 2014 18:18:47 -0300 Subject: [Aboriginal] legacy builds Message-ID: Hi, I've recently came across aboriginal and it felt like jackpot for the problems I currently have with my toolchain. I mainly target x86_64 but will try arm asap. I do mostly scientific HPC code and must support legacy kernel and compilers (think kernel 2.6 and gcc < 4.3). I would like to know if it is possible to do so, in principle, with AL. I did try changing the download.sh to point to older versions and it failed during patching obviously... I suspect it is possible, but would like to hear if I am going way over the project original design goals or if I should look for something else. My questions: - considering only x86_64 target builds, can I simply ignore those patches? How safe it is to assume it will create a working image? - should I build glibc for such old build? How hard would that be? - any timeline on musl libc? Thanks a lot and kudos for the educational tone of the project! Regards, Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Tue Jun 17 03:37:13 2014 From: rob at landley.net (Rob Landley) Date: Mon, 16 Jun 2014 22:37:13 -0500 Subject: [Aboriginal] legacy builds In-Reply-To: References: Message-ID: <539FB7E9.5060803@landley.net> On 06/16/14 16:18, Carlos Breviglieri wrote: > Hi, I've recently came across aboriginal and it felt like jackpot for > the problems I currently have with my toolchain. I mainly target x86_64 > but will try arm asap. I do mostly scientific HPC code and must support > legacy kernel and compilers (think kernel 2.6 and gcc < 4.3). The gcc I build is 4.2.1 with binutils 2.17 (the last gplv2 release of each). It's also simpler because they haven't broken out MPFR and GMP and such into separate packages yet. Downside: no armv7, armv8, or micrblaze support. (Might be able to fish armv7 out of the repo. Did so for binutils, haven't done so for gcc yet. More interested in http://ellcc.org long term.) > I would like to know if it is possible to do so, in principle, with AL. > I did try changing the download.sh to point to older versions and it > failed during patching obviously... I suspect it is possible, but would > like to hear if I am going way over the project original design goals or > if I should look for something else. Earlier versions of aboriginal linux built with earlier kernels, you can seach the repository history at http://landley.net/hg/aboriginal for those, and their corresponding patch stacks. For x86_64, you shouldn't need most of the patches. The main ones it won't build without are the perl removal patches, because perl isn't part of the build environment. The description in the old presentation is still reasonably accurate: http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu You can also just do "HOST_EXTRA=perl ./host-tools.sh" (I.E. export the environment variable and run the command), and it'll pass through perl from the host environment so the kernel builds without patches. (Perl showed up as a requirement in 2.6.25 and I finally got it to go away again here: http://landley.net/notes-2013.html#18-05-2013 (But you still need the bc patch for reasons explained there, or you can do HOST_EXTRA=bc (and if you need both, HOST_EXTRA="perl bc").) > My questions: > - considering only x86_64 target builds, can I simply ignore those > patches? How safe it is to assume it will create a working image? The kernel patches are mostly only needed to build the kernel. If you've got a kernel, life is good. Userspace is generally fairly flexible. (Occasionally uClibc has needed a patch to /usr/include/linux or similar. You can actually _read_ sources/patches/linux-*.patch, each one should have a description at the top.) > - should I build glibc for such old build? How hard would that be? > - any timeline on musl libc? I was actualy working on the musl wrapper earlier today. I sort of gave myself heatstroke on friday (more the "rehydrating by chugging an energy drink" than the actual dehydration; the blood pressure drop when those suddenly wear off in those circumstances is _scary_. My fingernails turned blue and I felt like I had food poisoning.) So this weekend was slighlty less productive than it could have been. And my attempt to do a more coherent, better organized version of my "rise and fall of copyleft" talk from ohio linuxfest... wasn't. Still, recovering now, trying to catch up. Found out that the uClibc I'm building doesn't have posix_fallocate (which is from posix 2001) so toybox defconfig build breaks because fallocate is in there now (since the function it needs has been in the standard for 13 years now), but it's only present in uClibc if the config symbol UCLIBC_HAS_ADVANCED_REALTIME is enabled. (*boggle* What does preallocating disk space have to do with advanced realtime?) That symbol is _enabled_ in sources/baseconfig-uClibc but not taking effect for some reason. I suppose I'll track it down this weekend or something, but in the meantime: excuse to poke at musl conversion. Backstory on said conversion is here: http://lists.landley.net/pipermail/aboriginal-landley.net/2014-May/001396.html Rob 1402976233.0