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!

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?

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 )If when you configure it you add useAnd then build you getAs 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 the final size comes toSizes 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.

I agree with ReaperX7. In some cases, using -O3 can break compilation (rare, but happens) and even slow down some programs.

-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.

What packages? what flags?

Never seen -Os I'll look it up.

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.

See here for explanation of gcc optimization flags https://gcc.gnu.org/onlinedocs/gcc/O...e-Options.html

-Ofast looks interesting, especially since I saw https://openbenchmarking.org/result/...GA-GCCOPTIMI95

1 members found this post helpful.

: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.