TheOldFellow wrote:
<snipage>
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.


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


<snip>
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}/config.site  #  this obviates the need for many
                                 # --prefix=/usr - where the gnu-autotools
                                 # have been properly used.

cat > ~/config.site << "EOF"
test "$prefix" = NONE && prefix=/tools
test -z "$CFLAGS" && CFLAGS="-O2 -pipe"
test -z "$CXXFLAGS" && CXXFLAGS=${CFLAGS}
enable_nls=no
EOF

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
#--------------
<snip>

See LDFLAGS issue at the top.

# Gcc-4.x pass1
#--------------
<snip>
make \
        BOOT_LDFLAGS=${LDFLAGS} \
        BOOT_CFLAGS="-O2 -pipe" \
        STAGE1_CFLAGS="-pipe" \
        LDFLAGS=${LDFLAGS} \
        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.


<snip>
# Adjust Toolchain
#-----------------
<snip>
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?


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

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 LDFLAGS=${LDFLAGS}
make install

# Binutils Pass 2
#------------------------------
<snip>
make LDFLAGS=${LDFLAGS}

LDFLAGS again.

<snip>
#=============================================================
# CHROOT
#=============================================================
<snip>
# 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.


<snip>
# Glibc-2.3.X
#------------
<snip>
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.

<snip>
# GCC-4.x
#--------
<snip>
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

make LDFLAGS=${LDFLAGS}

LDFLAGS again.

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

LDFLAGS again.

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

Is the autoconf version of standards.info better than the binutils version?

<snip>

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

--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to