Ken Moffat wrote:
>nfs-utils ? (all my source is on an nfs mount).
Heh, I build portmap, tcp-wrappers and nfs-utils
(all my source and homedirs are nfs mounts)
>Cross-compiling is a very educational experience, for those few who
>manage to complete it (I've cross-compiled kernels, cross-compiling a
>full system is more than an order of magnitude harder).
Not really, bootstrapping the c-libraries is the only hard part.
>But building in an absolutely-minimal new system is very much a
>"hair shirt" experience - do it if you have to, but it isn't
>something to seek out.
>Some of us have enough problems just getting our new systems
>to boot, forcing everybody to reboot into a "super-lean" system to
>build the real system would limit participation.
Responding more to Randy McMurchy here...
I think you guys are totally missing the point.
The 4 "serious" (LOL) pitfalls are not 4 but 1 (reboot into ${LFS},
and it is _bunk_
You can *still chroot* to do ch6 if you are on same arch (or an
earlier arch, say, i386 from i686... btw you can do this now
out of the box)
but
You can *also reboot* into ${LFS} if you so desire.
For folks upset about the build being non-minimalistic
1) extra tools get installed into /tools
2) we don't keep /tools
so the argument again is bunk, ch6 packages do *NOT* change
So if you
a) don't want to reboot, dont build the extra packages
b) want or *have* to reboot, build as much as you need
(tcp-wrappers, portmap, nfs-utils, openssh/ssl, lynx... whatever)
Now, what do we actually BUY with this build...
1) TOTAL divorce from the buildhost.
At no point do ANY host system headers or libs polute anything
under /tools.
2) No reliance on the running kernel version ch5
(hey, with the build of gnu tools on the host you can build from
solaris if you so desire)
3) Separation of the host tools (ie: initial compiler/binutils) etc
linked against the host system libraries from the produced tools
for target (ie: linked against the ch5 glibc), hence
4) No clobbering of gcc, binutils... no need for a specs edit ch5, and
no need for the keep binutils source dir around.
We produce 2 separate toolchains ch5, one is a cross-compiler,
the other is a target native compiler.
If you stuff up at any point ch5 go back to where you stuffed up
and restart the build painlessly (no more "start from scratch")
5) we can do multilib builds, regardless of the base OS
ie from an i686 livecd, build a bi-arch x86_64 to boot into.
THIS HERE is a BIG win...
6) we can do cross-platform builds, uni-arch or multi-arch, nptl
enabled or linuxthreads.
We can live with plfs style builds I suppose if you are only interested
in uni-arch x86 bitty boxes, and as has been noted that is 90% of our
audience... or should I say *CURRENT* audience.
Or we could actually live up to our projects name which last time
I checked was not "linux from linux" but "linux from scratch".
The new method doesn't have to be a major departure for same-arch
builds (and it isnt, plfs was nothing but a bastardised semi cross
build anyway using a cross-linker and a native compiler), and any
seeming "deficiencies" of rebooting into ${LFS} to complete the build
can be avoided (build what you need ch5) without compromising the
minimalistic *final* product.
Please folks, have a bit of a think about how things actually work,
or actually take a look at how it hangs together, before going off
the deep end
Regards
[R]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
