In this section we're going to install Glibc. But before we'll be able to install these libraries, we need to have a bunch of other software installed on the LFS system. Therefore all these programs need to be linked statically. This means quite a bit of extra work, because after Glibc and the GNU CC compilers are installed, we're going to re-install all these programs so they'll be linked dynamically. If somebody knows of a better way to accomplish this, without first building all the software statically and then rebuild them dynamically, please let me know.
I know of one other way and that's by installing Glibc using pre-compiled binaries. But that would be directly against what we're doing here. So that's not an option.
All software that is being installed in this section will be compiled on our normal working Linux system and then copied to the LFS system.
You'll notice that the installation of this software is very straightforward is most cases. I also won't explain what this software does, since it's all trivial software and if you don't know what some program does, you can always read the README file and other documentation.
configure
make LDFLAGS=-static
make
binary to $LFS/usr/bin
configure
make LDFLAGS=-static
sed/sed
binary to $LFS/usr/bin
configure
make LDFLAGS=-static
date echo false pwd sleep stty su true uname
chroot
basename dirname env expr factor groups id logname nice nohup pathchk printenv
printf seq tee test tty uptime users who whoami yes
configure
make LDFLAGS=-static
chgrp chmod chown cp dd df dir dircolors du ln ls mkdir mkfifo mknod mv rm
rmdir sync touch vdir
ginstall
$LFS/usr/bin/ginstall
file to $LFS/usr/bin/install
configure
make
make
LDFLAGS=-static
osetup mount swapon umount
$LFS/sbin/swapoff
to $LFS/sbin/swapon
configure
make LDFLAGS=-static
cat
cksum comm csplit cut expand fmt fold head join md5sum nl od paste pr sort
split sum tac tail tr unexpand uniq wc
configure
make LDFLAGS=-static
After compiling the programs in the src directory you will have two programs: tar and rmt. Tar is obvious. Rmt stands for ReMote Tapeserver. If you don't need this program (ie; you don't have a tapestreamer in your network or on your machine) then you don't need to copy this program.
src/tar
binary to $LFS/binsrc/rmt
binary to $LFS/bin (if you need it)
configure
make LDFLAGS=-static
I'm using version 1.2.4 and during the compilation process I'm getting this error: conflicting types for basename. If you're also being troubled by this error, here's how to fix it:
Recompile the package now (by running make LDFLAGS=-static again) and the error should be fixed.
What was wrong here? On my system there was a function called 'basename' in one of the standard system header files (I think it was string.h but I'm not sure anymore). The Gzip program has a function of it's own, also called basename and those two caused a collision if you will. By rename the Gzip specific basename function to basename2, the problem was solved.
gzexe.in zdiff.in zforce.in
zgrep.in zmore.in znew.in
gunzip gzexe gzip zcat zdiff
zforce zgrep zmore znew
configure
make LDFLAGS=-all-static
as-new gasp-new
$LFS/usr/bin/as
and $LFS/usr/bin/gasp
ld-new
$LFS/usr/bin/ld
addr2line ar c++filt nm-new objcopy objdump ranlib size strings strip-new
$LFS/usr/bin/nm
$LFS/usr/bin/strip
configure
make LDFLAGS=-static
egrep fgrep grep
configure
make LDFLAGS=-static
bison
bison.hairy bison.simple
configure
make CFLAGS="-O -static"
mawk
$LFS/usr/bin/awk
to $LFS/usr/bin/mawk
configure
make LDFLAGS=-static
I'm using version 4.1 and during the compilation I'm getting this error. Although it is a fatal error, the compilation process doesn't stop when the errors occurs, so you need to watch your compilation output closely to find out if you also get the following error: defs.h:304: conflicting types for `basename'
If you're also troubled by that error, here's how to fix it:
find/Makefile
file and find the variable: CFLAGSfind/defs.h
file and file this line: char *basename P_((char *fname));find/util.c
file and find this line: char *basename (fname)This line is separated over two lines ("char *" is on the first line and "basename (fname)" on the second line).
You don't need to keep it separated on two lines, but if you want that's perfectly OK. Do whatever you think looks best.
Recompile the package (by running make LDFLAGS=-static again) and it should compile correctly this time.
find
configure
make LDFLAGS=-static
cmp diff diff3 sdiff
make ldd
make ldconfig
$LFS/bin:ldd
$LFS/sbin: ldconfig
Configure
You can stick to all the default questions, except to the following.
When asked What is the file extension used for shared libraries? [so]
Answer with: none
When asked Any additional ld flags (NOT including libraries)? [-L/usr/local/lib]
Answer with: -L/usr/local/lib -static
When asked Do you wish to use dynamic loading? [y]
Answer with: n
make
perl
configure
make LDFLAGS=-static
m4
configure
make LDFLAGS=-static
makeinfo
configure
automake aclocal
$LFS/usr/share/automake
config.guess
config.sub install-sh mdate-sh missing mkinstalldirs elisp-comp ylwrap acinstall
*.am
files$LFS/usr/share/aclocal
*.m4
files
configure
make
autoconf autoheader autoreconf
autoscan autoupdate ifnames
$LFS/usr/share/autoconf
*.m4*
files
(in effect this means all *m4 and all *.m4f files)acconfig.h
acfunctions acheaders acidentifiers acprograms acmakevars
We're not going to installed the latest Glibc version, 2.1.2, but version 2.0.7pre6. The reason is that glibc 2.1.2 requires at least gcc 2.8 (or egcs 1.1). My system has gcc 2.7.2.3 thus I can't compile the glibc2.1.2 library. And I also don't want to upgrade my working Linux system to gcc 2.95.2 (which is the latest version at the time of writing this document). Upgrading a compiler isn't as easy as it sounds and I don't want to break things on this working system.
So therefore I have to install glibc 2.0.7pre6. However, we are going to install the gcc 2.95.2 compiler. We also need to install the gcc 2.7.2.3 compiler because certain software can't be compiled with gcc 2.95.2 (due to bugs in the programs that aren't really bugs but the gcc 2.95.2 compiler defines them as bugs. This is not a bug in the compiler, but changes in the C standard (if I understood it correctly)).
A note on the glibc-crypt package. The following is quoted from the glibc-crypt-README file on ftp://ftp.gnu.org/gnu/glibc:
-*-*-*-*-*- The add-on is not included in the main distribution of the GNU C library because some governments, mostly notable those of France, Russia and the US, have very restrictive rules governing the distribution and use of encryption software. Please read the node "Legal Problems" in the manual for more details. In particular, the US does not allow export of this software without a license, including via the Internet. So please do not download it from the main FSF FTP site at ftp.gnu.org if you are outside of the US. This software was completely developed outside the US. -*-*-*-*-*-
"This software" refers to the glibc-crypt package at ftp://ftp.gwdg.de/pub/linux/glibc/2.0.7pre6/. This law only affects people who don't live in the US. It's not prohibited to import DES software, so if you live in the US you can import it from that German site.
configure
--with-gnu-binutils --enable-shared --enable-add-ons=linuxthreads,crypt
configparms
containing the following:
# Begin configparms prefix=/usr slibdir=/lib sysconfdir=/etc # End configparms
make
/usr/lib/gcc-lib
to the usr/lib/gcc-lib
directory
on the normal Linux system.make install
/usr/lib/gcc-lib
symlinkYou can check if the GNU C Library seems to be working by running a dynamically
linked program that uses this library (like virtual every single program).
A simple test is running the ls
program that resides in the bin directory on
your normal Linux partition. If you can run this program without getting any
errors, than the GNU C Library seems to be installed correctly.