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.
makebinary to $LFS/usr/bin
sed/sedbinary to $LFS/usr/bin
date echo false pwd sleep stty su true uname
chgrp chmod chown cp dd df dir dircolors du ln ls mkdir mkfifo mknod rm rmdir sync touch vdir
osetup mount swapon umount
cksum comm csplit cut expand fmt fold head join md5sum nl od paste pr sort split sum tac tail tr unexpand uniq wc
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/tarbinary to $LFS/bin
src/rmtbinary to $LFS/bin (if you need it)
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
addr2line ar c++filt nm-new objcopy objdump ranlib size strings strip-new
egrep fgrep grep
make CFLAGS="-O -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/Makefilefile and find the variable: CFLAGS
find/defs.hfile and file this line: char *basename P_((char *fname));
find/util.cfile 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.
diff diff3 sdiff
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
config.guess config.sub install-sh mdate-sh missing mkinstalldirs elisp-comp ylwrap acinstall
autoconf autoheader autoreconf autoscan autoupdate ifnames
*.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 18.104.22.168 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 22.214.171.124 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
configparmscontaining the following:
# Begin configparms prefix=/usr slibdir=/lib sysconfdir=/etc # End configparms
usr/lib/gcc-libdirectory on the normal Linux system.
You 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.