The sources for a new service need not (and should not) be part of the GNU C Library itself. The developer retains complete control over the sources and its development. The links between the C library and the new service module consists solely of the interface functions.
Each module is designed following a specific interface specification.
For now the version is 2 (the interface in version 1 was not adequate)
and this manifests in the version number of the shared library object of
the NSS modules: they have the extension .2. If the interface
changes again in an incompatible way, this number will be increased.
Modules using the old interface will still be usable.
Developers of a new service will have to make sure that their module is created using the correct interface number. This means the file itself must have the correct name and on ElF systems the soname (Shared Object Name) must also have this number. Building a module from a bunch of object files on an ELF system using GNU CC could be done like this:
gcc -shared -o libnss_NAME.so.2 -Wl,-soname,libnss_NAME.so.2 OBJECTS
section `Link Options' in GNU CC, to learn more about this command line.
To use the new module the library must be able to find it. This can be
achieved by using options for the dynamic linker so that it will search
the directory where the binary is placed. For an ELF system this could be
done by adding the wanted directory to the value of
LD_LIBRARY_PATH.
But this is not always possible since some programs (those which run
under IDs which do not belong to the user) ignore this variable.
Therefore the stable version of the module should be placed into a
directory which is searched by the dynamic linker. Normally this should
be the directory `$prefix/lib', where `$prefix' corresponds to
the value given to configure using the --prefix option. But be
careful: this should only be done if it is clear the module does not
cause any harm. System administrators should be careful.
Go to the first, previous, next, last section, table of contents.