-----Original Message----- From: gobolinux-devel-boun...@lists.gobolinux.org [mailto:gobolinux-devel-boun...@lists.gobolinux.org] On Behalf Of Lucas C. Villa Real Sent: 19 July 2009 09:31 To: gobolinux-devel@lists.gobolinux.org Subject: Re: [gobolinux-devel] Bootstrap issues On Wed, Jul 15, 2009 at 6:23 PM, Rehan<rehan.k...@dsl.pipex.com> wrote: > Hi, Hi there, >> I've been playing around with the Bootstrap v1.1 and come across some >> issues, some of which I have 'fixed' and some not. >> >> I am initially trying to get it to do a native build just to get a feel for >> it. I'll run through the issues as I remember them. >Ok. Bootstrap development happens mainly in Subversion. The release >version isn't really indicated if you intend to generate a native >build; it's been used almost exclusively for cross compiling packages >to different architectures. I'll give that a try. >> 1) The cross-native.conf config file was missing from the svn Compile >> version I am running. I found a copy of this file by taking pot shots at >> older svn versions so that seems to be fixed (but may be wrong) >That file was removed from Compile because we don't really need it. It >was more of a hack to rollback from Cross mode into Native mode again, >but no applications should depend on it nowadays. Ok. At the time I was working through error messages being displayed by bootstrap and mitigating each one as it came up and it was looking for cross-native.conf. >> 2) Next was the function Get_System_Paths function in >> /Programs/Scripts/Functions/GoboLinux. BootStrap was error-ing on this but >> continuing on. This was fixed by re-writing the function, as suggested by >> detsch on irc, to : >> >> Function Get_System_Paths () { >> Parameters "$1" programpath >> find "${programpath}" -mindepth 2 | while read path >> do >> Programs_To_System_Path "${path}" >> done >> >> I'm not sure if this has implications for other scripts? >At which point you noticed the Get_System_Paths error? Starting a new >FS with the Subversion snapshot seems to be ok. Again the 1.1 version was choking on the process substitution used in that function (very early on, can't remember exactly, sorry ). The documentation for process substitution says that it's not entirely portable between shells so the above might be a better way to construct that function for improved compatibility.. >> 4) There were a couple of errors in the package config.in files (IIRC the BC >> config.in and one other, I forget now) which was fixed by adding the >> required first two lines deduced from looking at other packages config.in's. >Could you please provide patches for that against the SVN snapshot? >> This got me to the point where there were no errors from bootstrap and it >> was doing things consistently the same way on each invocation. I am at the >> point where it now downloads the chroot environment (this was failing I >> guess due to 2 above) and attempts to chrootcompile the first package. It >> seems that this gets stuck somehow and then goes into an endless loop of >> trying and re-trying the chrootcompile. There aren't any useful error >> messages that I can see, in fact chrootcompile seems to think it is doing ok >> and carries on. >> >> Anyone have any suggestions on how can I proceed from here? >I'd like to suggest you to try the SVN version. Bootstrap was created >with cross compiling in mind and only later I started to add support >for a Native build. I created only one Native port (for a Mac PPC), >bootstrapped from Ubuntu for that same hardware, so it's really likely >that you will step on some eventual bugs. > > can launch a script to build a minimal Native system to see what >happens, too. I'll do that and will keep an eye open to see how far it >goes. I'll certainly provide the patches when I try the svn version. Unfortunately, I wiped that machine so I'll have to reconstruct the scenario. Actually, I am looking into Firmware Linux at the moment. (http://impactlinux.com/fwl/) and trying to build gobolinux from that (the goal being to create a base system that can be extended to be a media player/router/voip box). I have a feeling that firmware linux and gobolinux's bootstrap system/chrootcompiling might be a very good fit with some hackage/modification as the approaches are divergent but ultimately have the same goal. Particularly interesting is that with firmware linux builds are 'native' all the time after the initial environment is created and can also use a distcc trick to reduce compile times for any supported quemu virtual machine. According to the text on the firmware linux site being able to do cross-compiles, effectively, natively, helps with certain issues that are hard to work around in a cross compiling environment. See 'why do things this way' near the bottom of http://impactlinux.com/fwl/documentation.html. I think most of what is needed is already in place, just some integration work required. The downside of the firmware linux approach is that qemu emulator support, rather than gcc cross-compiler support, becomes a hard dependency (if qemu doesn't emulate the processor/hardware you can't do it). I'd be interested in any thoughts on this approach. Regards Rehan
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
