On Mon, Jan 12, 2009 at 3:20 PM, Jeremy Huntwork <jhuntw...@linuxfromscratch.org> wrote: > Nathan Coulson wrote: >> I have been using a modified LFS (built for 32/64bit at the same time) >> and it worked well until the latest changes were introduced to trunk >> (that use the -B flag). Specifically GCC pass2 does not find crt0.o >> 32bit (just see's the 64bit). I was curious if this is what the >> buildsystem that 7.0 is going to be using, or if it is still a work in >> progress. >> >> I was a bit lost with the latest change, as to why it does not use >> /tools/lib or /tools/lib64 without -B as that would allow me to use my >> old work without deviating too far from LFS. > > I meant to have a message posted here before now, but things have been busy. > > I have been adapting Ryan's methods to LFS because I think that there > are certain improvements over what is currently in trunk. Specifically: > > * No need for ever specifying '-B/tools/lib' > * No more need to do a 'post install' adjustment of the toolchain in > chapter 5 > * No need to patch gcc in pass 2 to revert to previous functionality. > The gcc devs have said that the sysroot methodology is the 'correct path > forward' for cross compiling. Although the build as a whole is a native > build, it relies on cross-compilation early in the game, so making use > of the sysroot functionality leaves us where we want to be, now and > going forward, I feel. > > I have not used all of Ryan's configure switches and patches, because I > have not seen a need for some things on i686, PowerPC or x86_64 > multilib. Adding in the bare necessities illustrates the core changes > needed to get this working. > > I also have only added in what is necessary in chapter 5 up to and > including gcc pass 2. If you're doing multilib you'll notice that there > is not yet a 32-bit Glibc in chapter 6 added and there are no > --libdir=/usr/$LIBDIR switches either. Also, there is some explanatory > text missing. But, to give you an idea, here's what I have so far: > > http://www.linuxfromscratch.org/~jhuntwork/lfs-multilib/ > > To me, this is the way forward for 7.0. > > -- > JH > --
Thanks, I'll take a look (A cursory glance has a nice 'lack' of adjusting. cheers). I remember the last time I dealt with sysroot, trying to make a mingw32/djgpp toolchain (and failed, but it was at the start of the sysroot era) oh, and just to clarify, I have been using a working multilib setup at home for a few months now. Just that I couldn't adapt the new build method in chap 5. (I have no misguided ideals that multilib will be in LFS for a while) BTW, one thought that I've been having in my setup, is using /usr/lib for 64bit, and /usr/lib/32 for 32bit [and /usr/lib/32/bin for things like ncurses-config]. AFAIK not standardized, but I wanted to use one script that would work on a 32bit (my EeePC 701) and my 64bit desktop. (was going to experiment once I have my scripts updated with svn & fixed the build system). I have this dream of a pure 64bit system, with 32bit 'not' being a integrated part of it. (Only program I have left that uses 32bit is wine. Even dosemu runs on 64bit). Disclaimer: Above paragraph is my own ideal, and in no way am I suggesting that it should be the way forward. Just thought it may spark some thoughts into alternative setups. I just did not want to have to add a --libdir=/usr/lib64 on all my scripts so I can use them equally well on 32bit/64bit. [with the exception of multilib 32bit scripts] Saying that, I wonder how hard it would be to add 32bit mode to BLFS instead of the book... binutils/gcc multilib use /usr/lib just fine for both arch's leaving only glibc to stick somewhere... My dreams are too farfetched I fear. -- Nathan Coulson (conathan) ------ Location: Brittish Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
