Resources
	Main page	Bugs	Manual	Resources

Project Website

Mailing list subscription information, archives of all lists and the CVS archive can be found at the project website <http://sources.redhat.com/glibc>.

Mailing Lists

There are a number of mailing lists relevant to glibc development.  If you are interested in ongoing development you should subscribe to libc-alpha; other lists are more specific.

• libc-announce : general announcements about glibc releases.
  
• libc-alpha : public discussion about glibc development.  Questions or queries about core parts of glibc (not bugs) are appropriately discussed here.
  
• libc-hacker : private (but archived) list for glibc development.
  
• libc-ports : discussion about code included in the ports add-on and non-core parts of glibc (e.g. LinuxThreads).
  
• glibc-cvs : glibc CVS commits.
• glibc-bugs : every bug update from glibc bugzilla

IRC

The #glibc channel is registered on oftc.net and irc.freenode.net.

Getting CVS sources

CVS sources are available from the project website (as per the instructions).

$ cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc login
{enter "anoncvs" as the password}
$ cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc co libc

To also get the contributed ports add-on, follow that with:

$ cd libc
$ cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc co ports

Weekly snapshots are published at <ftp://sources.redhat.com/pub/glibc/snapshots>. Once untarred, you can immediately do cvs update in that directory to update via anonymous CVS.

Building

Building glibc is quite tricky and has a number of pitfalls, not the least of which include

• Never install over a live system. The connection between the individual parts of the glibc shared libraries is special. The libc.so shared library uses private interfaces in ld.so and vice versa. On a live system with dynamically linked applications if a new libc.so replaces an old one with a different internal ABI your system will be broken. libpthread.so, libm.so, and librt.so have similar problems. At a minimum, install into a separate chroot environment.
• There is a high possibility you will end up creating a different public ABI. If you were to begin distributing binaries they would at a minimum not work, and at best create a lot of confusion.

External Resources

Below are some tools that may help you to work with glibc

Documentation

• Building and Testing gcc/glibc cross toolchains
• Setting up a chroot Debian system
• The Single Unix Specification (for an overview of the standard and it's history see this or this).
• Ulrich Drepper's page contains many documents relevant to glibc development.

Tools

• strace : Strace is a debugging tool which prints out a trace of all the system calls made by a program.
• ltrace : Ltrace intercepts and records the dynamic library calls which are called by the executed process and the signals received by that process.
• ddd : An interface to gdb
• The standard ELF tools nm, objdump and readelf (see man pages and the GNU binutils documentation).
• Valgrind (x86 Linux) : With the tools that come with Valgrind, you can automatically detect many memory management and threading bugs, avoiding hours of frustrating bug-hunting, making your programs more stable. You can also perform detailed profiling, to speed up and reduce memory use of your programs.
• Profiling utilities
  • gprof is the standard profiler distributed with GNU binutils.
  • qprof is an alternative profiler for Linux on IA64 and i386 platforms.
  • oprofile is a Linux based system wide profiling tool.
• NPTL trace tool : a library-level trace tool for the NPTL threads library. It helps developers to detect and understand complex interactions (race conditions, contentions, dead-lock, etc) in multi-threaded programs without having to modify code. There is also a tool to visualise traces called Pajé (screenshot).

Coding Standards

In general, follow the GNU Coding Standards. Specific areas to be considered include

• Correct formatting of changelog entries; see the GNU standards and follow what already exists.
• Update copyright strings in modified files. Emacs users can use upd-copyr.el to do this automatically.
• Avoid trailing whitespace. Emacs users can use whitespace.el or a snippet like

  (defun fc-turn-on-show-trailing-whitespace ()
    "Set `show-trailing-whitespace' to t."
    (setq show-trailing-whitespace t))
  
  (mapc (lambda (hook)
          (add-hook hook 'fc-turn-on-show-trailing-whitespace))
        '(c-mode-hook))
  

Projects

• A few modules of the C library can be used on their own, as part of stand alone applications intended to be portable to hosts based on non-GNU C libraries. The GNU Portability Library (gnulib) has packaged some of these modules and provides instructions how to modify makefiles, configure.ac files, etc.
• toolchain.org runs nightly automated tests for several architectures, including glibc builds.
• The Open POSIX Test Suite is an open source test suite with the goal of performing conformance, functional, stress, and performance testing of the functions described in the IEEE Std 1003.1-2001 System Interfaces specification.
• Bull is creating a NPTL test suite, aimed to work in conjunction with the OPTS. More information can be found in the Bull forums.