What a slacker learned from building Linux from Scratch...
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
Rep:
To those interested in the "build it yourself" process I can also recommend the DIY Linux Reference buid. It's very like LFS but does things slightly differently. The guy behind DIY Linux, Greg Shafer, was once involved with the LFS project. I have built both as well as BLFS and CLFS but these were a long time ago so please don't ask me the specific differences in DIY and LFS builds.
There are also DIY automation tarballs available with scripts to automate the entire build process much like ALFS which is an automated LFS system using jhalfs. I would definitely recommend building the systems manually at least once but having done this the automated systems are very useful and make building an entire system very simple and reproducible.
Thanks for the initial post, Lufbery. I've looked at the LFS docs in the past but never tried to actually implement it. Maybe one day -- who knows? But what I did get from it was just how much effort Pat & His Merry Men put into making Slackware such a beautiful OS to install and use -- not that I didn't have an inkling already.
Have you thought about condensing your notes onto a simple static page so a curious onlooker like me could see what went into your trial & error? After reading something like that I can imagine yelling out, "It...could...work!" like Gene Wilder in Young Frankenstein.
Have you thought about condensing your notes onto a simple static page so a curious onlooker like me could see what went into your trial & error? After reading something like that I can imagine yelling out, "It...could...work!" like Gene Wilder in Young Frankenstein.
Yeah. I'm actually working on that now. I'm supplementing it with notes from two other guys on the LFS-dev mailing list. I'll post it in my LQ Blog when I'm done.
I've also been wanting to give this ago for a while, I'm trying to decide between DIY-Linux or LFS.
I did the same thing -- for many years, in fact.
I did LFS first for a couple of reasons:
The DIY folks recommend doing LFS first.
DIY hasn't been updated since some time in 2009. I'm not sure if it's still developed or if folks are still around to help out when one hits a snag.
Still, DIY looks good, and the instructions are probably pretty current despite being from last year.
One thing I discovered during this process, though, was that you really are on your own, and that's a good thing. At some point, you're going to hit a spot where you've got to interpret and understand the instructions or do some research on how a particular command works.
That's what makes LFS so nice. The explanatory text gives enough context and background that when you need to do some additional research, you go into it well-informed.
Another thing I discovered was that GNU/Linux is pretty robust. Even when something goes wrong, it is usually easy (though often tedious) to fix the problem and move on rather than scrapping the whole things and starting over.
I don't want to pre-empt Eric's reply, but what I'm doing at the moment is a weak subset of what he did to bootstrap Slackware64.
Thanks for sharing your notes so far!
Quote:
The problems, so far, are
(1) Older upstream packages that won't build with recent toolchain, libraries or whatever - patch (13.1 shipped a really old version), gpm, sysvinit, sysklogd, netkit-{ftp,rsh}. These can be dealt with by patching and/or upversioning. Google is your friend.
(2) Dependencies that LFS doesn't know or care about. Slackware is a coherent unified whole, and to reconstruct it accurately a lot of optional dependencies have to be baked in by building packages in the right order. The ldd command is your friend. Some of these are circular dependencies that require two passes. A few SlackBuilds sneakily use stuff you haven't built yet (wget inside usbutils and pciutils). Worst of all, there's gcc-gnat...
That's good information. I'd love to see some more detailed notes.
Quote:
Additionally, LFS isn't perfect. There are a few signs of recent neglect (lack of volunteers?) and as the authors point out it hasn't been optimised for practicality.
Good points, although LFS did just release version 6.7. And, from what I can tell, the LFS system is tight and robust. BLFS, on the other hand is suffering a little bit from a lack of volunteers. Still, the explanatory text in BLFS, and the additional material on their wiki, is pretty good even if some of the package versions are slightly out of date.
Quote:
The order of building packages in Chapter 6 is perverse and leads to some of the fragility people experience when they "go off-piste". But that's apparently an intentional part of the LFS learning experience.
I seriously think that past a certain point in chapter 6, the packages are listed in alphabetical order.
Quote:
The best part of this exercise is reading Pat's comments in his SlackBuilds, some of which are quite droll
If I may make one suggestion (and you probably know this already): you are probably going to want to build a text editor during the temporary tool chain phase. Otherwise, you're going to have trouble editing SlackBuild scripts from within the chroot environment.
Loved the writeup Drew. Always a pleasure reading your work, and exciting to see discussions at the system level rather than the application level.
I think you can avoid the need to build a text editor, because you can edit the files outside of your chroot with the host OS.
Also, on the cross-compiler front: do one thing at a time and always take notes for repeatability. You will need them! As you maybe found with LFS, el toolchain is quite picky when it comes to what other toolchains she will build. Imagine that irritation multiplied by some arbitrarily large number for cross compilers
If you're interested in cross compilation (or Canadian cross ... ), look up crosstool. It's a little out of date now, but the build matrix always interested me: http://www.kegel.com/crosstool/cross....43/buildlogs/
...the explanatory text in BLFS, and the additional material on their wiki, is pretty good even if some of the package versions are slightly out of date.
In those cases I've tried their Development BLFS (HTML) usually with good results. Just wanted to mention it.
How much harder is it to build LFS vs. Gentoo? Does LFS have any kind of package manager? How would you know what all of the dependencies are without it--ldd?
@ vik
lfs does not have an auto-dependency package manager. It relies on users created specifically for creating packages and installing them. This also prevents one package from installing data over another package. HOWEVER, the goal here is to use Slackware's native package manager. The whole point in LFS is to teach you how to build your own distribution starting with the tool chain.
@ topic in general
I understand that many want to do Slackware From Ready Mix... but if you are not going to dissimilar architectures (e.g. 32bit to 64bit to arm) why can't you just recompile everything in place ontop of a full Slackware? (e.g. use i486 and gradually compile and replace with i686 or some 32bit AMD cpu).
How much harder is it to build LFS vs. Gentoo? Does LFS have any kind of package manager? How would you know what all of the dependencies are without it--ldd?
Vik,
Gentoo is easier, but in a way it's more confusing. There are dozens of different compile options to choose from for most packages in Gentoo. LFS is straightforward in that it goes step by step and if you follow them precisely, it works.
Dependencies aren't an issue with LFS, but they were with BLFS. If you go from front to back in BLFS, it will all work. If you select a few packages you want, the book will list the dependencies, but the dependencies also have listed dependencies and it takes a while to work back through them all. It can become like a snowball traveling downhill and growing. Gentoo automatically downloads and compiles the necessary dependencies. It's fun to watch, but I still prefer Slackware by far.
It's been several years since I tried LFS or BLFS so things might have changed a bit. It sounds like it's time to do them again, just for the learning experience. I've forgotten most of it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.