Jeroen Kleijer wrote: > I'm trying to build a development environment that's completely > independant of the underlying OS so that when I do an upgrade of my OS, > it can't have any effect on my development environment with new quirks > in gcc or glibc.
Fair enough. > What I basically want is for example a /opt filesystem which would have > the following: > - /opt/glibc/<version-x> > - /opt/glibc/<version-y> > - /opt/binutils/<version-z> > - /opt/binutils/<version-a> > - /opt/gcc/<version-b> > - /opt/gcc/<version-c> Ughh, that looks very unwieldy, untidy and fragile. Something a bit saner would be: - /opt/toolchain-a - /opt/toolchain-b - /opt/toolchain-c where each toolchain consists of the gcc/glibc/binutils versions you require. > This way I could basically "recreate" the different versions of RedHat > EL by collecting their glibc / gcc / binutils versions, compile them > against each other and by "merely" (understatement, I know) setting my > PATH variable, I could have the compiler, libc and linker of my > choosing. > > Is such a setup feasible with the documentation found in LFS? IMHO no. LFS documents an exact procedure. To do what you want you'd need to go beyond and have more knowledge of GNU toolchain lore than LFS provides. > Are there > any caveats I should be aware of? Any suggestions? A much easier solution is to use chroots. Just keep around a filesystem image of whichever environments you need and chroot into'em to do your development. I do this all the time. Of course it chews up a fair amount of disk space. You could also go the virtual machine route (vmware, etc). Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
