Ready for gcc-4 & cleaning up binutils source delete or not.

Joel Miller cheeziologist at
Sat Apr 16 10:42:24 PDT 2005

TheOldFellow wrote:
A bit of a disclaimer before I try to pick apart this script a little. 
All internal politics discussions aside, I greatly respect Greg's 
technical prowess, and my trying to make changes to a script by some one 
who knows a lot more than me will probably break things. That said, here 
is what I would change to stay in line with LFS.

> LDFLAGS="-s"

The last time we explicity had the linker do stripping was LFS 4.x IIRC. 
Unless there is good reason to have this flag, we should probably drop it.

> TZ='Europe/London'  # the right timezone

This, I think, needs an explanation before we use it in the build. The 
only time thus far that we've needed to set TZ is to test one of the 
packages (I forget which).

> CONFIG_SITE=${HOME}/  #  this obviates the need for many
>                                  # --prefix=/usr - where the gnu-autotools
>                                  # have been properly used.
> cat > ~/ << "EOF"
> test "$prefix" = NONE && prefix=/tools
> test -z "$CFLAGS" && CFLAGS="-O2 -pipe"
> enable_nls=no

This is interesting and I didn't know you could do this. I'll play with 
this in my next build. The thing is though, as much as my personal 
builds use CFLAGS, CXXFLAGS, LDFLAGS, and --disable-nls, none of that is 
done in the book. Taking those out leaves this as just setting the 
prefix. Boils down to a judgement call by the editors I guess.

> # Greg builds copies of bash, make and sed to be certain that all
>   the scripts work even if the host-distro is quite odd/old.
> # Binutils pass1
> #--------------

See LDFLAGS issue at the top.

> # Gcc-4.x  pass1
> #--------------
> make \
> 	BOOT_CFLAGS="-O2 -pipe" \
> 	STAGE1_CFLAGS="-pipe" \
> 	bootstrap

Again, the flags thing. Unless there is a technical reason to leave them 
in, the book's policy thus far has been to not set CFLAGS, CXXFLAGS, and 
LDFLAGS for the user.

> # Adjust Toolchain
> #-----------------
> I=`gcc -print-file-name=include`
> rm -rfv ${I}/*
> J=`gcc -print-file-name=install-tools`
> cp -pv ${J}/include/* ${I}
> cp -pv ${J}/gsyslimits.h ${I}/syslimits.h
> # Comments:  ${I} is the absolute name of the library dir 'include' that gcc
> #            would use when linking.  ${J} is the same for 'install-tools'.
> #            So the script deletes the current contents of the 'include' dir,
> #            and copies the 'install-tools' version there instead.

As much as the comment here explains what it does in a physical sense, I 
can already see that. What I don't see is the bigger picture of why this 
is done. The README file tells me, I think,  that the 
install-tools/include/ directory is where the headers that were "fixed" 
by the fixincludes process get put. Is the above scriplet similar or the 
same to our fixincludes patch?

> # GCC-4.x Pass 2
> #-----------------
> sed -i.bak \
> 	-e 's,\./fixinc\.sh,-c true,' \
> 	-e '/^LIBGCC2_DEBUG/d' gcc/

Then again, the above sed looks more like the fixincludes patch as I 
think it prevents the fixincludes process from running.

> mkdir ../gcc-build
> cd ../gcc-build
> ../gcc-4*/configure \
> 	--with-local-prefix=/tools \
> 	--enable-shared \
> 	--enable-languages=c,c++ \
> 	--enable-clocale=gnu \
> 	--enable-threads=posix \
> 	--enable-__cxa_atexit \
> 	--disable-libstdcxx-pch
> make install
> # Binutils Pass 2
> #------------------------------

LDFLAGS again.

> #=============================================================
> #=============================================================
> # Man-Pages
> #---------------
> rm -fv man1/{chgrp,chmod,chown,cp,dd,df,diff,dir,dircolors,du}.1
> rm -fv man1/{install,ln,ls,mkdir,mkfifo,mknod,mv,rm,rmdir,touch,vdir}.1
> rm -fv man3/getspnam.3 man5/passwd.5

Interesting approach. Rather than install the man-pages and have them 
subsequently overwritten, simply prevent the man-pages versions from 
ever being installed. I personally disagree, and use the man-pages 
versions of the documents rather than the man pages provided by the 
specific packages, but seeing as the book does the opposite this is 
something the editors may want to consider even though it doesn't do 
much to change the end result.

> # Glibc-2.3.X
> #------------
> CFLAGS="-O3 -march=i686 -pipe" ../glibc-2.3.*/configure \

There is likely a reason that Greg decides to use different CFLAGS for 
glibc then for all the other packages. We need an explanation for this 
if we do it in the book. Of course, the book has been advocating the 
build of glibc without CFLAGS for a while now, which further begs an 
explanation. I personally think it's still a throwback from when 
linuxthreads would bomb if you set CFLAGS. I personally have built glibc 
many times with "-O2 -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse 
-fomit-frame-pointer -pipe" without issues. The -mfpmath=sse creates 
issues with the math tests, but it hasn't come back to bite me yet.

> 	--disable-profile \
> 	--enable-add-ons \
> 	--libexecdir=/usr/lib \
> 	--with-headers=/usr/include \
> 	--enable-kernel=2.6.0 \
> 	--enable-bind-now
> make
> make -k check || :

I'll assume that the || : is there for cut and paste scripting purposes.

> # GCC-4.x
> #--------
> CC="gcc -specs=/tmp/myspecs -B/usr/lib/ -B/usr/bin/" \

I thought the -B stuff was a "hack" and there was a proper way to fix 
the issues that FC-3 brought up. I, however, am not too familiar with 
the issue.

> 	../gcc-4*/configure \
> 	--libexecdir=/usr/lib \
> 	--enable-shared \
> 	--enable-languages=c,c++ \
> 	--enable-clocale=gnu \
> 	--enable-threads=posix \
> 	--enable-__cxa_atexit

LDFLAGS again.

> # Binutils
> make LDFLAGS=${LDFLAGS} tooldir=/usr

LDFLAGS again.

> make -k check || :
> sed -i.bak '/^INFO/s/ //' etc/Makefile

Is the autoconf version of better than the binutils version?


Well, those are my views anyways. Like I said in the beginning, I don't 
have the prowess Greg does, but I think the above are issues LFS should 
address before any of that is attempted.

Registered LFS User 6929
Registered Linux User 298182

More information about the lfs-dev mailing list