glibc 2.1 notes

[Joel Klecker <jk@espy.org>]

As some of you may know, glibc 2.1 will be uploaded to unstable as 
soon as slink is released.
There are a few issues that need documenting.

* It will be necessary to upgrade a few things in order to link 
against them, notably ncurses, slang, and libstdc++. I intend to NMU 
these things along with the glibc upload.

* glibc 2.1 has a helper daemon to manage the utmp and wtmp 
databases, an excerpt from README.utmpd follows (the readme doesn't 
mention it, but utmpd also allows programs to write utmp and wtmp 
entries without having root privileges).

<<
What is `utmpd' doing?
======================

After installation there will be two files that store the user
accounting information: `/var/run/utmp' and `/var/run/utmpx'.  The
file `/var/run/utmp' will be in the old format so libc5 programs will
continue to work (even if they are broken and do not use the library
functions to access the user accounting database).  And on Intel, you
can safely link `/var/run/utmp' to `/etc/utmp' for iBCS programs.
Programs linked against the new GNU C Library (glibc2) will contact
the daemon for all user accounting database access.  The daemon will
store its information in `/var/run/utmpx' and keeps this file in sync
with `/var/run/utmp'.  Entries added to `/var/run/utmpx' will be
converted to the old format and will be added to `/var/run/utmp' and
vice versa.  This way both libc5 and glibc2 see the same information
in the same fields of `struct utmp'. Of course libc5 programs see only
part of the information that glibc2 programs see because not all
members of the glibc2 `struct utmp' are present in the libc5 `struct
utmp'.  For the same reason libc5 will see a truncated version of
those fields where the length of the glibc2 field is larger than the
corresponding libc5 field (ut_user, ut_line, ut_host).
[...]
Programming
===========

In order for the `utmpd' approach to work it is essential that NO
program EVER accesses the UTMP and WTMP files directly.  Instead, a
program should use ONLY the available library functions:

    * utmpname()       Select the database used (UTMP, WTMP, ...).
    * setutent()       Open the database.
    * getutent()       Read the next entry from the database.
    * getutid()        Search for the next entry with a specific ID.
    * getutline()      Search for the next entry for a specific line.
    * pututline()      Write an entry to the database.
    * endutent()       Close the database.
    * updwtmp()        Add an entry to a database (WTMP, ...).

For details, please refer to `The GNU C Library Reference Manual',
which also contains information about some additional functions
derived from BSD and XPG that may be of interest.  The command

   info libc "User Accounting Database"

should point you at the right location.

If you encounter a program that reads from or, even worse, writes to
the UTMP and WTMP files directly, please report this as a bug to the
author of that program.  Note that the files referred to by the macros
`_PATH_UTMP' and `_PATH_WTMP' might even disappear in the future, so
please do not use these, except in a call to `utmpname()' or
`updwtmp()', not even to check their existence.
> >

Unfortunately I have discovered that even GNU software (`who' from 
shellutils) is guilty of reading the utmp file directly, I am sure we 
have other programs that don't do it the right way as well.
If you maintain a package with programs that work with utmp and/or 
wtmp. please check that they do it correctly.

* lintian's "compiled-with-bad-libc" tag trips on anything linked 
with glibc 2.1, but under glibc 2.1, __register_frame_info is defined 
in libc and as such is supposed to be undefined in executables.
--
Joel Klecker (aka Espy)                     <URL:http://web.espy.org/>
<URL:mailto:jk@espy.org>                  <URL:mailto:espy@debian.org>
Debian GNU/Linux PowerPC -- <URL:http://www.debian.org/ports/powerpc/>