Comments on LFS 2.4.4

Marc Heerdink marc_heerdink at
Sat Jan 27 13:38:18 PST 2001

On Sat, 27 Jan 2001 10:53:57 -0500, Simon Perreault wrote [Re: Comments on LFS 2.4.4]:
> On Saturday 27 January 2001 07:35, Marc Heerdink wrote:
> > I think this is not the most elegant way, since an environment variable get
> > set first (meant for the whole session) and gets destroyed 2 lines after it
> > has been defined. CPPFLAGS=-Dre_max_failures=re_max_failures2 ./configure
> > -blah does basically do the same, except the CPPFLAGS variable only exists
> > shortly. The export thingie should be saved for really important variables,
> > such as setting the CFLAGS variable permanently.
> Quoted from the changelog:
> Chapter 5: Instead of CPPFLAGS=-Dvar=value ./configure during the 
> installation of diffutils, grep and sed, we now use export 
> CPPFLAGS=-Dvar=value && ./configure && unset CPPFLAGS. This was done to
> get things working on some systems that don't work well with that
> construction.
Ok, sorry about this one.

> > but it is still in MAKEDEV.
> So what? If you need to "MAKEDEV audio", add the audio group.
Umm... since this book isn´t used only by linux gurus like you and me, give this some thought. Not everyone knows how to create groups or how to use them.

> > (that include common groups and users that are standard on
> > linux systems, such as "nobody"):
> If you need such users/groups, just create them.
Like my previous answer, with one addition: We´re trying to set up a _decent_ Linux system. And since every _decent_ linux system has at least these groups and users, I think they should be in LFS.

> > I quote: "Another, easier, option!s! is just not to compile programs
> > with debugging symbols." But how? I read this part over and over again, but
> > it's not stated anywhere. After doing some research, I think "export
> > LDFLAGS=-Wl,-S" is the answer.
> Quoted from the book, beginning of chapter 6:
> Most programs and libraries by default are compiled with debugging
> symbols and optimizing level 2 (gcc options -g and -O2)[...]
> I think it's clear.
I don´t think so. What I can read from these lines is: "If a program is compiled with the -g and -O2 switches, there will be debugging symbols in the binary." So you suggest I search every makefile to remove the -g and -Ox options from the gcc flags, to avoid my binaries having debugging symbols? I think my linker solution is much easier.

> > After selecting the timezone, a TZ value is returned. Don't waste it!
> put it in /etc/profile (TZ=Europe/Amsterdam; export TZ).
> Why so?
Your system time will be correctly mapped to programs that need this variable.

> > In syslog.conf: Every
> > distro I have ever used, had a /var/log/messages with the most
> important system messages. I think LFS needs one too.
> Fine, then add it to your own system. Don't forget that not everybody
> wants what you may think is neat.
I'm clearly not the only one that has thoughts like this.

> > The 3-number symlink setup looks cool, and has good arguments to
> > support it, but since the standard on SYSV init style is to have only 2
> > numbers, I think this convention should be followed. The more because LFS once
> > decided to follow this complicated way of booting, it should as unbloated as
> > possible.
> The booting scripts is an area where absolutely no convention exists.
> You can do it as you want, and it will always stay compatible with everything.
> You could start all your programs in inittab itself, if you wished so. And I
> don't think we can qualify this as bloat.
I do think so. Read my BSD style init hint and you'll know why I call this bloated. And _please_ remember that, although many people dislike it, RedHat is some sort of standard and many applications are set up for RedHat environments. Even the /etc/sysconfig dir is derived from RedHat, so the startup scripts should be like RedHats too.

> > I quote: "Edit the Makefile and edit the CFLAGS variable to use
> compiler optimizations." The compiler optimizations section was dropped in LFS
> > 2.4.4, so this is a leftover of 2.4.3.
> I think Gerard should remove that, you're right.
Ah finally ;)

Marc Heerdink
marc_heerdink at

Unsubscribe: send email to lfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the lfs-dev mailing list