Setting up glibc dev environment
These instructions a just a quick (and terse) run through on how you can setup and develop glibc should you need to.
Get & build libc
cvs -z 9 -d :pserver:firstname.lastname@example.org:/cvs/glibc login [anoncvs] cvs -z 9 -d :pserver:email@example.com:/cvs/glibc co libc
build libc, using separate object directory as required
mkdir glibc-obj cd glibc-obj ../libc/configure --prefix=/usr --enable-add-ons=nptl --prefix=/usr
It is very important to set --prefix=/usr
Create a chroot
debootstrap sid ./the-chroot ftp://ftp.au.debian.org/debian/
You might like to setup the chroot (install gcc, fix up the /etc/apt/sources list, etc) and then make a tar of it, so that when you break it you can just delete it and untar the new one. You might also like to modify /etc/bash.bashrc to give you a different prompt so you know you are in the chroot.
TO install glibc, you need in addition to what debootstrap provides:
On the other hand, you can delete a whole heap of stuff;
- parted and libparted
Create a script
Create a script to
- bind mount the source and object directories into the chroot
- chroot you
- optionally change back to a normal user, etc.
as an example
if [ ! -d ./the-chroot/usr/src/libc ] ; then sudo mkdir ./the-chroot/usr/src/libc fi if [ ! -d ./the-chroot/usr/src/libc-obj ] ; then sudo mkdir ./the-chroot/usr/src/libc-obj fi sudo mount --bind libc ./the-chroot/usr/src/libc sudo mount --bind libc-obj ./the-chroot/usr/src/libc-obj sudo chroot ./the-chroot sudo umount ./the-chroot/usr/src/libc sudo umount ./the-chroot/usr/src/libc-obj
Install new libc
Debian ships the NPTL libraries in /lib/tls (correctly), but for our development version we don't really care about having the correct libraries setup. Since make install won't put things in /lib/tls, if it exists the new version that we install will look at the hardware capabilites, decide to check for optimised libraries in the tls subdirectory and find them, only to completely fail when they are totally the wrong version.
The simplest way to avoid that is to set LD_ASSUME_KERNEL=2.4.0 to fool the dynamic loader into not looking for these files, then delete /lib/tls and install your new system (since we enabled tls with --enable-tls they'll be TLS libraries anyway).
Inside the chroot!
LD_ASSUME_KERNEL=2.4.0 rm -rf /lib/tls cd /usr/src/libc-obj make install
once you have installed, you can unset the LD_ASSUME_KERNEL since the new libraries will be quite happy with everything in the default place. Of course this isn't as robust, and if you do go back to a kernel that can't support the latest libraries it won't work. But this is just for development, not production!
Now you can just make your changes outside your chroot, and thanks to the bind mount install them inside your chroot and do any testing you require.
If you specify
CFLAGS=-O2 -gdwarf-2 -g3
gcc will do some macro expansion and generally provide you with a nicer debugging experience (n.b. you need the O2 as libc won't build without optimisation on). The trade off is disk space used.