Differences between revisions 9 and 10
Revision 9 as of 2014-01-23 14:27:20
Size: 7041
Comment:
Revision 10 as of 2014-01-23 14:54:47
Size: 7211
Comment:
Deletions are marked like this. Additions are marked like this.
Line 65: Line 65:
You will need to use '''{{{lib}}}''' on 32-bit systems. You will need to use '''{{{lib}}}''' on 32-bit systems or 64-bit systems that use '''`lib`''' like Ubuntu.
Line 138: Line 138:
  -I${SYSROOT}/include \
Line 158: Line 159:
  -I${SYSROOT}/include \
Line 163: Line 165:
You will need to use '''{{{lib}}}''' on 32-bit systems, and adjust '''{{{ld-2.18.90.so}}}''' for the version of glibc. You will need to use '''{{{lib}}}''' on 32-bit systems or 64-bit systems that use '''`lib`''' like Ubuntu.

You will nee
d to adjust '''{{{ld-2.18.90.so}}}''' for the version of glibc.

Testing a glibc build

So you want to test out a glibc build, and you don't want to install it over your existing system glibc. Not installing glibc over your existing system glibc is the normal process. Installing a new glibc over your system glibc may break your system, do not do this unless you really know what you're doing.

You need to do two things:

  • Decide how to build your glibc
  • Decide how to build your application

First we go through the two ways to build glibc:

Building glibc without installing

To build glibc without installing you can do the standard configure and make e.g.

$ mkdir $HOME/src
$ cd $HOME/src
$ git clone git://sourceware.org/git/glibc.git
$ mkdir -p $HOME/build/glibc
$ cd $HOME/build/glibc
$ $HOME/src/glibc/configure --prefix=/usr
$ make

Do not run make install.

By building with the prefix /usr you have created a glibc that will load and use all configuration files from the standard locations. The prefix /usr is considered the correct prefix for a system glibc. More advanced users will note that the prefix is actually part of the glibc ABI.

Lastly if you want to build with an alternate set of Linux kernel headers you will need to use --with-headers= to point to a unified installation of Linux headers and other headers required by glibc during the build which may or may not include SELinux headers.

Building glibc with intent to install

Do configure with a --prefix install directory that you can write to, then make and make install e.g.

$ export INSTALLDIR=<path to the GLIBC install directory>
$ mkdir $HOME/src
$ cd $HOME/src
$ git clone git://sourceware.org/git/glibc.git
$ mkdir -p $HOME/build/glibc
$ cd $HOME/build/glibc
$ $HOME/src/glibc/configure --prefix=/usr
$ make
$ make install DESTDIR=${INSTALLDIR}

You now have the newly built glibc installed to /install and you can build applications that run against it.

Then you will need a set of linux kernel headers:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ make headers_install INSTALL_HDR_PATH="${INSTALLDIR}/usr"

Lastly you will need gcc's helper library for cancellation:

$ cp /lib64/libgcc* "${INSTALLDIR}/lib64/"

This leaves you with a ready to use system root in ${INSTALLDIR}.

You will need to use lib on 32-bit systems or 64-bit systems that use lib like Ubuntu.

Compile normally, run under new glibc

Use this if you want to be able to run your application easily with the newly built libc and then again with the system libc for comparison.

Compile your test program, and invoke it with the newly loader you built. This is also how the make check runs tests. Note: if the executable under test resides in the current directory, don't forget to use ./ before the name.

Use either testrun.sh in the build directory e.g.

$ cd $HOME/build/glibc
$ ./testrun.sh /path/to/test/application

Or do this manually like this:

GLIBC=<path to the GLIBC build directory>

GCONV_PATH=${GLIBC}/iconvdata LC_ALL=C     \
${GLIBC}/elf/ld.so.1 --library-path \
${GLIBC}:\
${GLIBC}/math:\
${GLIBC}/elf:\
${GLIBC}/dlfcn:\
${GLIBC}/nss:\
${GLIBC}/nis:\
${GLIBC}/rt:\
${GLIBC}/resolv:\
${GLIBC}/crypt:\
${GLIBC}/nptl:\
${GLIBC}/dfp \
<executable to test> <arguments>

Please note that such a compilation does not make use of new C runtime objects i.e. crt1.o, crti.o, and crtn.o provided by glibc. Changes made to these objects require a more complex compilation. Compiling with -Wl,-Map,linker.map will show you exactly which objects were used in the final link.

Compile against glibc build tree

Use this method if you want to easily debug your application but haven't installed glibc.

BUILD=<path to the GLIBC build directory>

gcc \
  -Wl,-rpath=${GLIBC}:\
${GLIBC}/math:\
${GLIBC}/elf:\
${GLIBC}/dlfcn:\
${GLIBC}/nss:\
${GLIBC}/nis:\
${GLIBC}/rt:\
${GLIBC}/resolv:\
${GLIBC}/crypt:\
${GLIBC}/nptl:\
${GLIBC}/dfp \
  -Wl,--dynamic-linker=${BUILD}/lib/ld.so
  <other compiler flags> -o <application> <application>.c

Please note that such a compilation does not make use of new C runtime objects i.e. crt1.o, crti.o, and crtn.o provided by glibc. Changes made to these objects require a more complex compilation. Compiling with -Wl,-Map,linker.map will show you exactly which objects were used in the final link.

Compile against glibc in an installed location

Use this method if you want to easily debug your application.

Compile your test program and give some extra options to gcc to use the install directory, and some options to the linker to set the shared library search path and dynamic linker. It is a good idea to verify the location of the dynamic linker using "readelf" and the library search paths with "ldd". (See loader tips and tricks)

SYSROOT=<path to the GLIBC install directory>
gcc \
  -L${SYSROOT}/usr/lib64 \
  -I${SYSROOT}/include \
  --sysroot=${SYSROOT} \
  -Wl,-rpath=${SYSROOT}/lib64 \
  -Wl,--dynamic-linker=${SYSROOT}/lib64/ld-2.18.90.so\
  <other compiler flags> -o <application> <application>.c

The built application will now always use the dynamic loader and libraries from the paths you compiled it with.

If your static linker lacks sysroot support you can try this instead:

  • Edit ${SYSROOT}/usr/lib64/libpthread.so to point to your sysroot libpthread.so.1.
  • Edit ${SYSROOT}/usr/lib64/libc.so to point to your sysroot libc.so.6.
  • Then build without --sysroot.

SYSROOT=<path to the GLIBC install directory>
gcc \
  -L${SYSROOT}/usr/lib64 \
  -I${SYSROOT}/include \
  -Wl,-rpath=${SYSROOT}/lib64 \
  -Wl,--dynamic-linker=${SYSROOT}/lib64/ld-2.18.90.so \
  <other compiler flags> -o <application> <application>.c

You will need to use lib on 32-bit systems or 64-bit systems that use lib like Ubuntu.

You will need to adjust ld-2.18.90.so for the version of glibc.

Required gdb setup

One special step needs to be taken to debug an application using a new glibc build with gdb. The thread db library must be explicitly set. The debugger can't easily guess the correct version and location of the thread db library used to inspect the current threading state. If you installed glibc the debugger will often find libthread_db.so without any problems, but if you didn't install glibc then you will certainly have problems trying to debug threaded code using the system library. Therefore it's always safest to specify exactly where to search for the thread db library.

Execute this in gdb before debugging:

set libthread-db-search-path <path to libthread_db.so.1 e.g. /build/glibc/nptl_db or /install/lib64/>

None: Testing/Builds (last edited 2014-01-23 14:54:47 by CarlosODonell)