[SOLVED] absolute necessary packages to build a basic system?
Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
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.
absolute necessary packages to build a basic system?
hey guys. I followed the lfs book and made my own lfs distro and image. But the system all together is about 900 MB, which is bigger than I thought. I actually found some image from internet that is about 500 MB big and works all fine, it even got things like apt and dpkg.
I went through the list again, can't really judge by now which are the necessary packages. I mean, I probably will remove man-db and bison. But others I'm just not sure.
it would be awesome if you guys can share about the which packages I can throw out. Thanks!
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,150
Rep:
Unless you have specifically set the make flags when building your basic system you should be able to save quite a bit of space by changing from the default -g -O2 to -O3, removing the -g will not include debug symbols and -O3 adds a bit more optimizion, also don't forget to strip the binarys, but frankly do you need to save a couple of hundred megs? in this day and age of 1T+drive saving such a amall amount seems futile, even if you plan to put your system on a usb stick you are probably stll looking at having a least a couple of gigs.
Unless you have specifically set the make flags when building your basic system you should be able to save quite a bit of space by changing from the default -g -O2 to -O3, removing the -g will not include debug symbols and -O3 adds a bit more optimizion, also don't forget to strip the binarys, but frankly do you need to save a couple of hundred megs? in this day and age of 1T+drive saving such a amall amount seems futile, even if you plan to put your system on a usb stick you are probably stll looking at having a least a couple of gigs.
hey Keith, thanks for the reply. I'm building it on a embedded system so every MB counts. I know busybox could be a better option but I am not sure how hard is it to compile gcc on it. So I thought it's better just try to shrink the lfs system at first...
and the binaries? can you indicate where are they or how it should be done? you mean the chapter 5.35 and 6.71?
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,150
Rep:
All the stuff from chapter 5 is in the tools folder when you have built your real system you should have removed the tools folder, the bianary's are all the stuff in /bin, /usr/bin, /lib and /usr/lib.
Fair enough if you are building on an embedded system, I wouldn't bother stripping etc the tool chain or changing the build flags as you are going to get rid of it but for instance when building 'less' in chapter 6 without chanchanging the make flags you get this ( exerpt from stat )
As you can see the second version without the -g flag and with -O3 instead of the default -O2 results in a file thats less than half the size of the original, if you then use
Sizes will vary slightly depending on your system, there are other problems with such agresize optimization/stripping ie debugging would be a nightmare.
All the stuff from chapter 5 is in the tools folder when you have built your real system you should have removed the tools folder, the bianary's are all the stuff in /bin, /usr/bin, /lib and /usr/lib.
Fair enough if you are building on an embedded system, I wouldn't bother stripping etc the tool chain or changing the build flags as you are going to get rid of it but for instance when building 'less' in chapter 6 without chanchanging the make flags you get this ( exerpt from stat )
As you can see the second version without the -g flag and with -O3 instead of the default -O2 results in a file thats less than half the size of the original, if you then use
Sizes will vary slightly depending on your system, there are other problems with such agresize optimization/stripping ie debugging would be a nightmare.
thanks for the reply! that indeed was very helpful!
I will be forward on this, but be careful with optimization -O3. A lot of packages will work well with it, but the safest bet is -O2 so you don't break anything.
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,150
Rep:
-O3 optimization should never break compilation of code and I have never seen this, it can in certain cases make the code less efficient if the code is self modifying and what would usually be run in the cpu cache needs to be constantly refreshed because of that modifacation, it's a case of suck it and see but the OP is concerned with sueezing every last byte out of OS so it is a possible saving, the OP would have to decide if the savings outway the possible code slowdown.
I've seen build failures on few packages that use -Werror and certain warning flags. -O3 would trigger a warning on such packages and -Werror would cause gcc to fail.
As for the size, there's also -Os flag (optimize for size), which should provide fair optimization, while reducing overall size.
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,150
Rep:
Quote:
Originally Posted by Krejzi
I've seen build failures on few packages that use -Werror and certain warning flags. -O3 would trigger a warning on such packages and -Werror would cause gcc to fail.
As for the size, there's also -Os flag (optimize for size), which should provide fair optimization, while reducing overall size.
I think it may have been mutter (GNOME's compositor). I just turned off warning flags by passing --enable-warnings=minimum or something like that to configure, so I don't know which flag caused it.
I think it may have been mutter (GNOME's compositor). I just turned off warning flags by passing --enable-warnings=minimum or something like that to configure, so I don't know which flag caused it.
:thumbup: for the references. I saw it once and couldn't remember where I saw it.
Anyway, for embedded systems and small/old laptops, -Os maybe the best option, which seems to be -O2 minus flags that would increase the size. Unless if the performance outweighs the size, in which case one would opt for -O3.
Also, I wonder if these options are used for building small distros like tinycore?
In the past when I ran Gentoo at times, using optimization level -O3 often resulted in broken package builds which caused me numerous reinstalls, so I have sense stuck to -O2 unless recommended or utilized in the makefiles by the package upstream authors. Back in kernel 2.6.xx I broke a few kernel modules for realtek hardware this way as well.
Yes, it shouldn't break things.
I once saw a makefile for an experimental build of the emulator bsnes (before it was melded into higan) with about 15~20 compile time optimizations literally that made me cringe. When I ran it with verbose output, just for shits and giggles, it spat out warnings like no tomorrow.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.