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

2005-04-18 Thread Bryan Kadzban
Matthew Burgess wrote:
 [EMAIL PROTECTED] wrote:
 
 I suppose though we'll need 2 host compilers, we'll need a 3.4 for 
 the kernel builds etc
 
 Why?

I'm just guessing here, but I would bet that it'll be similar to the gcc
2.95 / gcc 3.X upgrade.  The kernel documentation said to use 2.95 (and
still does, in fact), so that's what we did, until it started causing
problems with the NPTL tests.


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


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

2005-04-16 Thread TheOldFellow
I think it might be time to get ready for the imminent release of gcc-4.
 The key thing that needs to be fixed in the (unstable) book is the
management of gcc's specs.

I've learnt quite a bit about this from Greg Shafer's scripts, and
attached you'll find a somewhat LFS-ised set of instructions with my
comments on how the method works.  There isn't any rocket science here,
but a handy listing of Gcc's man page is helpful in understanding this -
and it works fine with gcc-3 too.  The section entitled 'Options for
Debugging Your Program or GCC' is the relevant bit.

I'm also attracted to Greg's method of carrying binutils information
forward.  I like it most because it removes that newbie confusion over
'shall I delete the sources?'.  This is worth incorporating just for itself.

Of course, we could start lfs-hackers again...   ;-)

# Greg's environment variables

LC_ALL=POSIX

LDFLAGS=-s

PATH=/tools/bin:/bin:/usr/bin  # Make sure /tools/bin comes first during
   # the toolchain build, replacing the host's.

TZ='Europe/London'  # the right timezone

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

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

mkdir ../binutils-build
cd ../binutils-build

../binutils-2*/configure
make LDFLAGS=${LDFLAGS}
make install

make -C ld clean
make -C ld \
LDFLAGS=${LDFLAGS} \
LIB_PATH=/tools/lib
cp -v ld/ld-new /tools/bin

# Comments:  Binutils takes note of the site config file to pick up the prefix.
#The cp saves a copy of ld/ld-new for the toolchain adjustment, so
#that we can delete the binutils files now.  This avoids a lot of
#newbie confusion!
 
# Gcc-4.x  pass1
#--

sed -i.bak \
'/^LIBGCC2_DEBUG/d' gcc/Makefile.in

mkdir ../gcc-build
cd ../gcc-build

../gcc-4*/configure \
--with-local-prefix=/tools \
--disable-shared \
--enable-languages=c \
--with-ld=/tools/bin/ld \
--with-as=/tools/bin/as
make \
BOOT_LDFLAGS=${LDFLAGS} \
BOOT_CFLAGS=-O2 -pipe \
STAGE1_CFLAGS=-pipe \
LDFLAGS=${LDFLAGS} \
bootstrap
make install
ln -sv gcc /tools/bin/cc

# Comments:  --with-local-prefix puts the compiler in the tools dir. 
#--with-ld and --with-as pick up the right linker and assembler
#to  use from where we put them when we built binutils.
#I guess the sed just stops gcc building debug facilities,
#probably to speed up the build?   

# Linux-Libc-Headers
#

cp -Rv include/asm-i386 /tools/include/asm
cp -Rv include/linux /tools/include

# Glibc-2.3.X
#

mkdir ../glibc-build
cd ../glibc-build

../glibc-2.3.*/configure \
--disable-profile \
--enable-add-ons \
--with-binutils=/tools/bin \
--with-headers=/tools/include \
--without-selinux
make \
AUTOCONF=no \
libgcc_eh= \
static-gnulib=-lgcc
make install

# Comments:   Few surprises here.  I need to understand the make parameters.

# Adjust Toolchain
#-

M=`gcc -dumpmachine`
cp -pv /tools/bin/ld-new /tools/bin/ld
cp -pv /tools/bin/ld-new /tools/${M}/bin/ld

# Comments:   This is the equivalent of 'make -C ld install' in LFS,
# but it's neater, since the sources don't hang about.
# ${M} is the host triple e.g. i686-pc-linux-gnu.

gcc -dumpspecs | sed \
s,/lib/ld-linux.so.2,/tools,  \
`gcc -print-search-dirs | head -n 1 | awk '{ print $2 }'`specs

# Comments:  This finds all the /lib/ld-linux.so.2 occurances in the dump of
#the specs, and replaces them with /tools/lib/... overwriting
#the file 'specs' in gcc's installation directory.

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.

echo 'main(){}' | cc -x c -
readelf -l a.out | grep : /tools
rm -fv a.out

# Comments: This is just the check that the specs have been adjusted OK.

# GCC-4.x Pass 2
#-

sed -i.bak \
s@/lib/[EMAIL PROTECTED]/tools@ gcc/config/i386/linux.h
echo 
/* Remove /usr/include from end of include search path.  

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

2005-04-16 Thread Andrew Benton
Jeremy Utley wrote:
And the simple 
fact is, GCC 4.0 is not quite yet ready for integration into the LFS 
book - it probably won't be until 4.0.3 or thereabouts.
But still, it would be nice to have a crack at chewing on the bugs
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page