GNU Gnulib

GNU Gnulib
1 Introduction
2 Invoking gnulib-tool
3 Miscellaneous Notes
4 Building the ISO C and POSIX Substitutes
5 ISO C and POSIX Header File Substitutes
6 ISO C and POSIX Function Substitutes
7 Past POSIX Function Substitutes
8 Glibc Header File Substitutes
9 Glibc Function Substitutes
10 Particular Modules
Appendix A GNU Free Documentation License
Index

GNU Gnulib

This manual is for GNU Gnulib (updated 2009-05-23 22:24:22), which is a library of common routines intended to be shared at the source level.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

1 Introduction

Gnulib is a source code library. It provides basic functionalities to programs and libraries. Currently (as of October 2006) more than 30 packages make use of Gnulib.

1.1 Benefits of using Gnulib

1.2 Library vs. Reusable Code

Classical libraries are installed as binary object code. Gnulib is different: It is used as a source code library. Each package that uses Gnulib thus ships with part of the Gnulib source code. The used portion of Gnulib is tailored to the package: A build tool, called gnulib-tool, is provided that copies a tailored subset of Gnulib into the package.

1.3 Portability and Application Code

One of the goals of Gnulib is to make portable programming easy, on the basis of the standards relevant for GNU (and Unix). The objective behind that is to avoid a fragmentation of the user community into disjoint user communities according to the operating system, and instead allow synergies between users on different operating systems.

Another goal of Gnulib is to provide application code that can be shared between several applications. Some people wonder: "What? glibc doesn't have a function to copy a file?" Indeed, the scope of a system's libc is to implement the relevant standards (ISO C99, POSIX:2001) and to provide access functions to the kernel's system calls, and little more.

For example, Gnulib has a facility for generating the name of backup files. While this task is entirely at the application level — no standard specifies an API for it — the naïve code has some portability problems because on some platforms the length of file name components is limited to 30 characters or so. Gnulib handles that.

Similarly, Gnulib has a facility for executing a command in a subprocess. It is at the same time a portability enhancement (it works on GNU, Unix, and Windows, compared to the classical fork/exec idiom which is not portable to Windows), as well as an application aid: it takes care of redirecting stdin and/or stdout if desired, and emits an error message if the subprocess failed.

1.4 Modules

Gnulib is divided into modules. Every module implements a single facility. Modules can depend on other modules.

A module consists of a number of files and a module description. The files are copied by gnulib-tool into the package that will use it, usually verbatim, without changes. Source code files (.h, .c files) reside in the lib/ subdirectory. Autoconf macro files reside in the m4/ subdirectory. Build scripts reside in the build-aux/ subdirectory.

The module description contains the list of files — gnulib-tool copies these files. It contains the module's dependencies — gnulib-tool installs them as well. It also contains the autoconf macro invocation (usually a single line or nothing at all) — gnulib-tool ensures this is invoked from the package's configure.ac file. And also a Makefile.am snippet — gnulib-tool collects these into a Makefile.am for the tailored Gnulib part. The module description and include file specification are for documentation purposes; they are combined into MODULES.html.

The module system is the basis of gnulib-tool. When gnulib-tool copies a part of Gnulib into a package, it first compiles a module list, starting with the requested modules and adding all the dependencies, and then collects the files, configure.ac snippets and Makefile.am snippets.

1.5 Various Kinds of Modules

There are modules of various kinds in Gnulib. For a complete list of the modules, see in MODULES.html.

1.5.1 Support for ISO C or POSIX functions.

When a function is not implemented by a system, the Gnulib module provides an implementation under the same name. Examples are the ‘snprintf’ and ‘readlink’ modules.

Similarly, when a function is not correctly implemented by a system, Gnulib provides a replacement. For functions, we use the pattern

and implement the foo function under the name rpl_foo. This renaming is needed to avoid conflicts at compile time (in case the system header files declare foo) and at link/run time (because the code making use of foo could end up residing in a shared library, and the executable program using this library could be defining foo itself).

For header files, such as stdbool.h or stdint.h, we provide the substitute only if the system doesn't provide a correct one. The template of this replacement is distributed in a slightly different name, with an added underscore, so that on systems which do provide a correct header file the system's one is used.

1.5.2 Enhancements of ISO C or POSIX functions

These are sometimes POSIX functions with GNU extensions also found in glibc — examples: ‘getopt’, ‘fnmatch’ — and often new APIs — for example, for all functions that allocate memory in one way or the other, we have variants which also include the error checking against the out-of-memory condition.

1.5.3 Portable general use facilities

Examples are a module for copying a file — the portability problems relate to the copying of the file's modification time, access rights, and extended attributes — or a module for extracting the tail component of a file name — here the portability to Woe32 requires a different API than the classical POSIX basename function.

1.5.4 Reusable application code

Examples are an error reporting function, a module that allows output of numbers with K/M/G suffixes, or cryptographic facilities.

1.5.5 Object oriented classes

Examples are data structures like ‘list’, or abstract output stream classes that work around the fact that an application cannot implement an stdio FILE with its logic. Here, while staying in C, we use implementation techniques like tables of function pointers, known from the C++ language or from the Linux kernel.

1.5.6 Interfaces to external libraries

Examples are the ‘iconv’ module, which interfaces to the iconv facility, regardless whether it is contained in libc or in an external libiconv. Or the ‘readline’ module, which interfaces to the GNU readline library.

1.5.7 Build / maintenance infrastructure

An example is the ‘maintainer-makefile’ module, which provides extra Makefile tags for maintaining a package.

1.6 Collaborative Development

Gnulib is maintained collaboratively. The mailing list is <bug-gnulib at gnu dot org>. Be warned that some people on the list may be very active at some times and unresponsive at other times.

Every module has one or more maintainers. While issues are discussed collaboratively on the list, the maintainer of a module nevertheless has a veto right regarding changes in his module.

All patches should be posted the list, regardless whether they are proposed patches or whether they are committed immediately by the maintainer of the particular module. The purpose is not only to inform the other users of the module, but mainly to allow peer review. It is not uncommon that several people contribute comments or spot bugs after a patch was proposed.

Conversely, if you are using Gnulib, and a patch is posted that affects one of the modules that your package uses, you have an interest in proofreading the patch.

1.7 Copyright

Most modules are under the GPL. Some, mostly modules which can reasonably be used in libraries, are under LGPL. The source files always say "GPL", but the real license specification is in the module description file. If the module description file says "GPL", it means "GPLv3+" (GPLv3 or newer, at the licensee's choice); if it says "LGPL", it means "LGPLv3+" (LGPLv3 or newer, at the licensee's choice).

More precisely, the license specification in the module description file applies to the files in lib/ and build-aux/. Different licenses apply to files in special directories:

If you want to use some Gnulib modules under LGPL, you can do so by passing the option ‘--lgpl’ to gnulib-tool. This will replace the GPL header with an LGPL header while copying the source files to your package. Similarly, if you want some Gnulib modules under LGPLv2+ (Lesser GPL version 2.1 or newer), you can do so by passing the option ‘--lgpl=2’ to gnulib-tool.

Keep in mind that when you submit patches to files in Gnulib, you should license them under a compatible license. This means that sometimes the contribution will have to be LGPL, if the original file is available under LGPL. You can find out about it by looking for a "License: LGPL" information in the corresponding module description.

1.8 Steady Development

Gnulib modules are continually adapted, to match new practices, to be consistent with newly added modules, or simply as a response to build failure reports. We don't make releases, but instead recommend to use the newest version of Gnulib from the Git repository, except in periods of major changes. The source tree can also be fetched from a read-only CVS that mirrors the Git repository.

1.9 Openness

Gnulib is open in the sense that we gladly accept contributions if they are generally useful, well engineered, and if the contributors have signed the obligatory papers with the FSF.

2 Invoking gnulib-tool

The gnulib-tool command is the recommended way to import Gnulib modules. It is possible to borrow Gnulib modules in a package without using gnulib-tool, relying only on the meta-information stored in the modules/* files, but with a growing number of modules this becomes tedious. gnulib-tool simplifies the management of source files, Makefile.ams and configure.ac in packages incorporating Gnulib modules.

gnulib-tool is not installed in a standard directory that is contained in the PATH variable. It needs to be run directly in the directory that contains the Gnulib source code. You can do this either by specifying the absolute filename of gnulib-tool, or you can also use a symbolic link from a place inside your PATH to the gnulib-tool file of your preferred and most up-to-date Gnulib checkout, like this:

Run ‘gnulib-tool --help’ for information. To get familiar with gnulib-tool without affecting your sources, you can also try some commands with the option ‘--dry-run’; then gnulib-tool will only report which actions it would perform in a real run without changing anything.

2.1 Initial import

Gnulib assumes your project uses Autoconf and Automake. Invoking ‘gnulib-tool --import’ will copy source files, create a Makefile.am to build them, generate a file gnulib-comp.m4 with Autoconf M4 macro declarations used by configure.ac, and generate a file gnulib-cache.m4 containing the cached specification of how Gnulib is used.

Our example will be a library that uses Autoconf, Automake and Libtool. It calls strdup, and you wish to use gnulib to make the package portable to C89 and C99 (which don't have strdup).

By default, the source code is copied into lib/ and the M4 macros in m4/. You can override these paths by using --source-base=DIRECTORY and --m4-base=DIRECTORY. Some modules also provide other files necessary for building. These files are copied into the directory specified by ‘AC_CONFIG_AUX_DIR’ in configure.ac or by the --aux-dir=DIRECTORY option. If neither is specified, the current directory is assumed.

gnulib-tool can make symbolic links instead of copying the source files. The option to specify for this is ‘--symlink’, or ‘-s’ for short. This can be useful to save a few kilobytes of disk space. But it is likely to introduce bugs when gnulib is updated; it is more reliable to use ‘gnulib-tool --update’ (see below) to update to newer versions of gnulib. Furthermore it requires extra effort to create self-contained tarballs, and it may disturb some mechanism the maintainer applies to the sources. For these reasons, this option is generally discouraged.

gnulib-tool will overwrite any pre-existing files, in particular Makefile.am. Unfortunately, separating the generated Makefile.am content (for building the gnulib library) into a separate file, say gnulib.mk, that could be included by your handwritten Makefile.am is not possible, due to how variable assignments are handled by Automake.

Consequently, it is a good idea to choose directories that are not already used by your projects, to separate gnulib imported files from your own files. This approach is also useful if you want to avoid conflicts between other tools (e.g., gettextize that also copy M4 files into your package. Simon Josefsson successfully uses a source base of gl/, and a M4 base of gl/m4/, in several packages.

After the ‘--import’ option on the command line comes the list of Gnulib modules that you want to incorporate in your package. The names of the modules coincide with the filenames in Gnulib's modules/ directory.

Some Gnulib modules depend on other Gnulib modules. gnulib-tool will automatically add the needed modules as well; you need not list them explicitly. gnulib-tool will also memorize which dependent modules it has added, so that when someday a dependency is dropped, the implicitly added module is dropped as well (unless you have explicitly requested that module).

If you want to cut a dependency, i.e., not add a module although one of your requested modules depends on it, you may use the option ‘--avoid=module’ to do so. Multiple uses of this option are possible. Of course, you will then need to implement the same interface as the removed module.

A few manual steps are required to finish the initial import. gnulib-tool printed a summary of these steps.

First, you must ensure Autoconf can find the macro definitions in gnulib-comp.m4. Use the ACLOCAL_AMFLAGS specifier in your top-level Makefile.am file, as in:

You are now ready to call the M4 macros in gnulib-comp.m4 from configure.ac. The macro gl_EARLY must be called as soon as possible after verifying that the C compiler is working. Typically, this is immediately after AC_PROG_CC, as in:

The core part of the gnulib checks are done by the macro gl_INIT. Place it further down in the file, typically where you normally check for header files or functions. It must come after other checks which may affect the compiler invocation, such as AC_MINIX. For example:

gl_INIT will in turn call the macros related with the gnulib functions, be it specific gnulib macros, like gl_FUNC_ALLOCA or autoconf or automake macros like AC_FUNC_ALLOCA or AM_FUNC_GETLINE. So there is no need to call those macros yourself when you use the corresponding gnulib modules.

You must also make sure that the gnulib library is built. Add the Makefile in the gnulib source base directory to AC_CONFIG_FILES, as in:

You must also make sure that make will recurse into the gnulib directory. To achieve this, add the gnulib source base directory to a SUBDIRS Makefile.am statement, as in:

or if you, more likely, already have a few entries in SUBDIRS, you can add something like:

Finally, you have to add compiler and linker flags in the appropriate source directories, so that you can make use of the gnulib library. Since some modules (‘getopt’, for example) may copy files into the build directory, top_builddir/lib is needed as well as top_srcdir/lib. For example:

Don't forget to #include the various header files. In this example, you would need to make sure that ‘#include <string.h>’ is evaluated when compiling all source code files, that want to make use of strdup.

In the usual case where Autoconf is creating a config.h file, you should include config.h first, before any other include file. That way, for example, if config.h defines ‘restrict’ to be the empty string on a pre-C99 host, or a macro like ‘_FILE_OFFSET_BITS’ that affects the layout of data structures, the definition is consistent for all include files. Also, on some platforms macros like ‘_FILE_OFFSET_BITS’ and ‘_GNU_SOURCE’ may be ineffective, or may have only a limited effect, if defined after the first system header file is included.

Finally, note that you can not use AC_LIBOBJ or AC_REPLACE_FUNCS in your configure.ac and expect the resulting object files to be automatically added to lib/libgnu.a. This is because your AC_LIBOBJ and AC_REPLACE_FUNCS invocations from configure.ac augment a variable @LIBOBJS@ (and/or @LTLIBOBJS@ if using Libtool), whereas lib/libgnu.a is built from the contents of a different variable, usually @gl_LIBOBJS@ (or @gl_LTLIBOBJS@ if using Libtool).

2.2 Modified imports

If you only want to use more Gnulib modules, simply invoke gnulib-tool --import new-modules. gnulib-tool remembers which modules were used last time. The list of modules that you pass after ‘--import’ is added to the previous list of modules.

For most changes, such as added or removed modules, or even different choices of ‘--lib’, ‘--source-base’ or ‘--aux-dir’, there are two ways to perform the change.

The standard way is to modify manually the file gnulib-cache.m4 in the M4 macros directory, then launch ‘gnulib-tool --import’.

The other way is to call gnulib-tool again, with the changed command-line options. Note that this doesn't let you remove modules, because as you just learned, the list of modules is always cumulated. Also this way is often impractical, because you don't remember the way you invoked gnulib-tool last time.

The only change for which this doesn't work is a change of the ‘--m4-base’ directory. Because, when you pass a different value of ‘--m4-base’, gnulib-tool will not find the previous gnulib-cache.m4 file any more... A possible solution is to manually copy the gnulib-cache.m4 into the new M4 macro directory.

2.3 Simple update

When you want to update to a more recent version of Gnulib, without changing the list of modules or other parameters, a simple call does it:

Note: From time to time, changes are made in Gnulib that are not backward compatible. When updating to a more recent Gnulib, you should consult Gnulib's NEWS file to check whether the incompatible changes affect your project.

2.4 Changing your sources for use with Gnulib

Gnulib contains some header file overrides. This means that when building on systems with deficient header files in /usr/include/, it may create files named string.h, stdlib.h, stdint.h or similar in the build directory. In the other source directories of your package you will usually pass ‘-I’ options to the compiler, so that these Gnulib substitutes are visible and take precedence over the files in /usr/include/.

These Gnulib substitute header files rely on <config.h> being already included. Furthermore <config.h> must be the first include in every compilation unit. This means that to all your source files and likely also to all your tests source files you need to add an ‘#include <config.h>’ at the top. Which source files are affected? Exactly those whose compilation includes a ‘-I’ option that refers to the Gnulib library directory.

This is annoying, but inevitable: On many systems, <config.h> is used to set system dependent flags (such as _GNU_SOURCE on GNU systems), and these flags have no effect after any system header file has been included.

2.5 Caveat: gettextize and autopoint users

The programs gettextize and autopoint, part of GNU gettext, import or update the internationalization infrastructure. Some of this infrastructure, namely ca. 20 autoconf macro files and the config.rpath file, is also contained in Gnulib and may be imported by gnulib-tool. The use of gettextize or autopoint will therefore overwrite some of the files that gnulib-tool has imported, and vice versa.

Avoiding to use gettextize (manually, as package maintainer) or autopoint (as part of a script like autoreconf or autogen.sh) is not the solution: These programs also import the infrastructure in the po/ and optionally in the intl/ directory.

The copies of the conflicting files in Gnulib are more up-to-date than the copies brought in by gettextize and autopoint. When a new gettext release is made, the copies of the files in Gnulib will be updated immediately.

2.6 Handling Gnulib's own message translations

Gnulib provides some functions that emit translatable messages using GNU gettext. The ‘gnulib’ domain at the Translation Project collects translations of these messages, which you should incorporate into your own programs.

There are two basic ways to achieve this. The first, and older, method is to list all the source files you use from Gnulib in your own po/POTFILES.in file. This will cause all the relevant translatable strings to be included in your POT file. When you send this POT file to the Translation Project, translators will normally fill in the translations of the Gnulib strings from their “translation memory”, and send you back updated PO files.

However, this process is error-prone: you might forget to list some source files, or the translator might not be using a translation memory and provide a different translation than another translator, or the translation might not be kept in sync between Gnulib and your package. It is also slow and causes substantial extra work, because a human translator must be in the loop for each language and you will need to incorporate their work on request.

For these reasons, a new method was designed and is now recommended. If you pass the --po-base=directory and --po-domain=domain options to gnulib-tool, then gnulib-tool will create a separate directory with its own POTFILES.in, and fetch current translations directly from the Translation Project (using rsync or wget, whichever is available). The POT file in this directory will be called domain-gnulib.pot, depending on the domain you gave to the --po-domain option (typically the same as the package name). This causes these translations to reside in a separate message domain, so that they do not clash either with the translations for the main part of your package nor with those of other packages on the system that use possibly different versions of Gnulib. When you use these options, the functions in Gnulib are built in such a way that they will always use this domain regardless of the default domain set by textdomain.

In order to use this method, you must – in each program that might use Gnulib code – add an extra line to the part of the program that initializes locale-dependent behavior. Where you would normally write something like:

you should add an additional bindtextdomain call to inform gettext of where the MO files for the extra message domain may be found:

(This example assumes that the domain that you specified to gnulib-tool is the same as the value of the PACKAGE preprocessor macro.)

Since you do not change the textdomain call, the default message domain for your program remains the same and your own use of gettext functions will not be affected.

2.7 Issues with Version Control Systems

If a project stores its source files in a version control system (VCS), such as CVS, SVN, or Git, one needs to decide which files to commit.

All files created by gnulib-tool, except gnulib-cache.m4, should be treated like generated source files, like for example a parser.c file is generated from parser.y.

2.8 Bundling the unit tests of the Gnulib modules

You can bundle the unit tests of the Gnulib modules together with your package, through the ‘--with-tests’ option. Together with ‘--with-tests’, you also specify the directory for these tests through the ‘--tests-base’ option. Of course, you need to add this directory to the SUBDIRS variable in the Makefile.am of the parent directory.

The advantage of having the unit tests bundled is that when your program has a problem on a particular platform, running the unit tests may help determine quickly if the problem is on Gnulib's side or on your package's side. Also, it helps verifying Gnulib's portability, of course.

The unit tests will be compiled and run when the user runs ‘make check’. When the user runs only ‘make’, the unit tests will not be compiled.

In the SUBDIRS variable, it is useful to put the Gnulib tests directory after the directory containing the other tests, not before:

This will ensure that on platforms where there are test failures in either directory, users will see and report the failures from the tests of your program.

Note: In packages which use more than one invocation of gnulib-tool in the scope of the same configure.ac, you cannot use ‘--with-tests’. You will have to use a separate configure.ac in this case.

3 Miscellaneous Notes

3.1 Comments

Where to put comments describing functions: Because of risk of divergence, we prefer to keep most function describing comments in only one place: just above the actual function definition. Some people prefer to put that documentation in the .h file. In any case, it should appear in just one place unless you can ensure that the multiple copies will always remain identical.

3.2 Header files

It is a tradition to use CPP tricks to avoid parsing the same header file more than once, which might cause warnings. The trick is to wrap the content of the header file (say, foo.h) in a block, as in:

Whether to use FOO_H or _FOO_H is a matter of taste and style. The C89 and C99 standards reserve all identifiers that begin with an underscore and either an uppercase letter or another underscore, for any use. Thus, in theory, an application might not safely assume that _FOO_H has not already been defined by a library. On the other hand, using FOO_H will likely lead the higher risk of collisions with other symbols (e.g., KEY_H, XK_H, BPF_H, which are CPP macro constants, or COFF_LONG_H, which is a CPP macro function). Your preference may depend on whether you consider the header file under discussion as part of the application (which has its own namespace for CPP symbols) or a supporting library (that shouldn't interfere with the application's CPP symbol namespace).

Adapting C header files for use in C++ applications can use another CPP trick, as in:

The idea here is that __cplusplus is defined only by C++ implementations, which will wrap the header file in an ‘extern "C"’ block. Again, whether to use this trick is a matter of taste and style. While the above can be seen as harmless, it could be argued that the header file is written in C, and any C++ application using it should explicitly use the ‘extern "C"’ block itself. Your preference might depend on whether you consider the API exported by your header file as something available for C programs only, or for C and C++ programs alike.

Note that putting a #include in an extern "C" { ... } block yields a syntax error in C++ mode on some platforms (e.g., glibc systems with g++ v3.3 to v4.2, AIX, OSF/1, IRIX). For this reason, it is recommended to place the #include before the

extern
"C"

block.

Include ordering

When writing a gnulib module, or even in general, a good way to order the ‘#include’ directives is the following.

3.3 Out of memory handling

The GSS API does not have a standard error code for the out of memory error condition. Instead of adding a non-standard error code, this library has chosen to adopt a different strategy. Out of memory handling happens in rare situations, but performing the out of memory error handling after almost all API function invocations pollute your source code and might make it harder to spot more serious problems. The strategy chosen improves code readability and robustness.

For most applications, aborting the application with an error message when the out of memory situation occurs is the best that can be wished for. This is how the library behaves by default.

However, we realize that some applications may not want to have the GSS library abort execution in any situation. The GSS library supports a hook to let the application regain control and perform its own cleanups when an out of memory situation has occurred. The application can define a function (having a void prototype, i.e., no return value and no parameters) and set the library variable xalloc_fail_func to that function. The variable should be declared as follows.

The GSS library will invoke this function if an out of memory error occurs. Note that after this the GSS library is in an undefined state, so you must unload or restart the application to continue call GSS library functions. The hook is only intended to allow the application to log the situation in a special way. Of course, care must be taken to not allocate more memory, as that will likely also fail.

3.4 Obsolete modules

Modules can be marked obsolete. This means that the problems they fix don't occur any more on the platforms that are reasonable porting targets now. gnulib-tool warns when obsolete modules are mentioned on the command line, and by default ignores dependencies from modules to obsolete modules. When you pass the option --with-obsolete to gnulib-tool, dependencies to obsolete modules will be included, however, unless blocked through an --avoid option. This option is useful if your package should be portable even to very old platforms.

In order to mark a module obsolete, you need to add this to the module description:

3.5 Library version handling

The module ‘check-version’ can be useful when your gnulib application is a system library. You will typically wrap the call to the check_version function through a library API, your library header file may contain:

To avoid ELF symbol collisions with other libraries that use the ‘check-version’ module, add to config.h through a AC_DEFINE something like:

The stringprep_check_version function will thus be implemented by the check_version module.

There are two uses of the interface. The first is a way to provide for applications to find out the version number of the library it uses. The application may contain diagnostic code such as:

Separating the library and header file version can be useful when searching for version mismatch related problems.

The second uses is as a rudimentary test of proper library version, by making sure the application get a library version that is the same, or newer, than the header file used when building the application. This doesn't catch all problems, libraries may change backwards incompatibly in later versions, but enable applications to require a certain minimum version before it may proceed.

3.6 Windows sockets

There are several issues when building applications that should work under Windows. The most problematic part is for applications that use sockets.

Hopefully, we can add helpful notes to this section that will help you port your application to Windows using gnulib.

3.6.1 Getaddrinfo and WINVER

This was written for the getaddrinfo module, but may be applicable to other functions too.

The getaddrinfo function exists in ws2tcpip.h and -lws2_32 on Windows XP. The function declaration is present if WINVER >= 0x0501. Windows 2000 does not have getaddrinfo in its WS2_32.DLL.

Thus, if you want to assume Windows XP or later, you can add AC_DEFINE(WINVER, 0x0501) to avoid compiling to (partial) getaddrinfo implementation.

If you want to support Windows 2000, don't do anything. The replacement function will open WS2_32.DLL during run-time to see if there is a getaddrinfo function available, and use it when available.

3.7 Libtool and Windows

If you want it to be possible to cross-compile your program to MinGW and you use Libtool, you need to put:

in your configure.ac. This sets the correct names for the OBJDUMP, DLLTOOL, and AS tools for the build.

If you are building a library, you will also need to pass -no-undefined to make sure Libtool produces a DLL for your library. From a Makefile.am:

3.8 License Texinfo sources

Gnulib provides copies of the GNU GPL, GNU LGPL, and GNU FDL licenses in Texinfo form. (The master location is http://www.gnu.org/licenses/). These Texinfo documents do not have any node names and structures built into them; for your manual, you should @include them in an appropriate @node.

The conventional name for the GPL node is ‘Copying’ and for the FDL ‘GNU Free Documentation License’. The LGPL doesn't seem to have a conventional node name.

3.9 Build robot for gnulib

To simplify testing on a wide set of platforms, gnulib is built on many platforms every day and the results are uploaded to:

If you wish to help the gnulib development effort with build logs for your favorite platform, you may perform these steps:

4 Building the ISO C and POSIX Substitutes

You can extract the ISO C / POSIX substitutes part of gnulib by running the command

The command ‘posix-modules’ is found in the same directory as gnulib-tool.

The resulting directory can be built on a particular platform, independently of the program being ported. Then you can configure and build any program, by setting CPPFLAGS and LDFLAGS at configure time accordingly: set CPPFLAGS="-I.../posixlib/lib", plus any essential type definitions and flags that you find in .../posixlib/config.h, and set LDFLAGS=".../posixlib/lib/libgnu.a".

This way of using Gnulib is useful when you don't want to modify the program's source code, or when the program uses a mix between C and C++ sources (requiring separate builds of the posixlib for the C compiler and for the C++ compiler).

5 ISO C and POSIX Header File Substitutes

This chapter describes which header files specified by ISO C or POSIX are substituted by Gnulib, which portability pitfalls are fixed by Gnulib, and which (known) portability problems are not worked around by Gnulib.

The notation “Gnulib module: —” means that Gnulib does not provide a module providing a substitute for the header file. When the list “Portability problems not fixed by Gnulib” is empty, such a module is not needed: No portability problems are known. Otherwise, it indicates that such a module would be useful but is not available: No one so far found this header file important enough to contribute a substitute for it. If you need this particular header file, you may write to <bug-gnulib at gnu dot org>.

5.1 aio.h

5.2 arpa/inet.h

5.3 assert.h

5.4 complex.h

5.5 cpio.h

5.6 ctype.h

5.7 dirent.h

5.8 dlfcn.h

5.9 errno.h

5.10 fcntl.h

5.11 fenv.h

5.12 float.h

5.13 fmtmsg.h

5.14 fnmatch.h

5.15 ftw.h

5.16 glob.h

5.17 grp.h

5.18 iconv.h

5.19 inttypes.h

5.20 iso646.h

5.21 langinfo.h

5.22 libgen.h

5.23 limits.h

5.24 locale.h

5.25 math.h

5.26 monetary.h

5.27 mqueue.h

5.28 ndbm.h

5.29 net/if.h

5.30 netdb.h

5.31 netinet/in.h

5.32 netinet/tcp.h

5.33 nl_types.h

5.34 poll.h

5.35 pthread.h

5.36 pwd.h

5.37 regex.h

5.38 sched.h

5.39 search.h

5.40 semaphore.h

5.41 setjmp.h

5.42 signal.h

5.43 spawn.h

5.44 stdarg.h

5.45 stdbool.h

5.46 stddef.h

5.47 stdint.h

The stdint.h module uses #include_next. If you wish to install the generated stdint.h file under another name, typically in order to be able to use some of the types defined by stdint.h in your public header file, you could use the following Makefile.am-snippet:

5.48 stdio.h

5.49 stdlib.h

5.50 string.h

5.51 strings.h

5.52 stropts.h

5.53 sys/ipc.h

5.54 sys/mman.h

5.55 sys/msg.h

5.56 sys/resource.h

5.57 sys/select.h

5.58 sys/sem.h

5.59 sys/shm.h

5.60 sys/socket.h

5.61 sys/stat.h

5.62 sys/statvfs.h

5.63 sys/time.h

5.64 sys/timeb.h

5.65 sys/times.h

5.66 sys/types.h

5.67 sys/uio.h

5.68 sys/un.h

5.69 sys/utsname.h

5.70 sys/wait.h

5.71 syslog.h

5.72 tar.h

5.73 termios.h

5.74 tgmath.h

5.75 time.h

5.76 trace.h

5.77 ucontext.h

5.78 ulimit.h

5.79 unistd.h

5.80 utime.h

5.81 utmpx.h

5.82 wchar.h

5.83 wctype.h

5.84 wordexp.h

6 ISO C and POSIX Function Substitutes

This chapter describes which functions and function-like macros specified by ISO C or POSIX are substituted by Gnulib, which portability pitfalls are fixed by Gnulib, and which (known) portability problems are not worked around by Gnulib.

The notation “Gnulib module: —” means that Gnulib does not provide a module providing a substitute for the function. When the list “Portability problems not fixed by Gnulib” is empty, such a module is not needed: No portability problems are known. Otherwise, it indicates that such a module would be useful but is not available: No one so far found this function important enough to contribute a substitute for it. If you need this particular function, you may write to <bug-gnulib at gnu dot org>.

6.1 FD_CLR

6.2 FD_ISSET

6.3 FD_SET

6.4 FD_ZERO

6.5 _Exit

6.6 _exit

6.7 _longjmp

Note: A future revision of POSIX later than the 2008/2009 one may drop the functions _setjmp and _longjmp. Still, in 2008, on all systems which have _setjmp, it is the fastest way to save the registers but not the signal mask (up to 30 times faster than setjmp on some systems).

6.8 _setjmp

6.9 _tolower

6.10 _toupper

6.11 a64l

6.12 abort

6.13 abs

6.14 accept

6.15 access

6.16 acos

6.17 acosf

6.18 acosh

6.19 acoshf

6.20 acoshl

6.21 acosl

6.22 aio_cancel

6.23 aio_error

6.24 aio_fsync

6.25 aio_read

6.26 aio_return

6.27 aio_suspend

6.28 aio_write

6.29 alarm

6.30 alphasort

6.31 asctime

6.32 asctime_r

6.33 asin

6.34 asinf

6.35 asinh

6.36 asinhf

6.37 asinhl

6.38 asinl

6.39 assert

Extension: Gnulib offers a module ‘assert’ that allows the installer to disable assertions through a ‘configure’ option: ‘--disable-assert’.

6.40 atan

6.41 atan2

6.42 atan2f

6.43 atan2l

6.44 atanf

6.45 atanh

6.46 atanhf

6.47 atanhl

6.48 atanl

6.49 atexit

6.50 atof

6.51 atoi

6.52 atol

6.53 atoll

6.54 basename

6.55 bind

6.56 bsearch

6.57 btowc

6.58 cabs

6.59 cabsf

6.60 cabsl

6.61 cacos

6.62 cacosf

6.63 cacosh

6.64 cacoshf

6.65 cacoshl

6.66 cacosl

6.67 calloc

Extension: Gnulib provides a module ‘calloc’ that substitutes a calloc implementation that behaves more like the glibc implementation.

6.68 carg

6.69 cargf

6.70 cargl

6.71 casin

6.72 casinf

6.73 casinh

6.74 casinhf

6.75 casinhl

6.76 casinl

6.77 catan

6.78 catanf

6.79 catanh

6.80 catanhf

6.81 catanhl

6.82 catanl

6.83 catclose

6.84 catgets

6.85 catopen

6.86 cbrt

6.87 cbrtf

6.88 cbrtl

6.89 ccos

6.90 ccosf

6.91 ccosh

6.92 ccoshf

6.93 ccoshl

6.94 ccosl

6.95 ceil

6.96 ceilf

6.97 ceill

6.98 cexp

6.99 cexpf

6.100 cexpl

6.101 cfgetispeed

6.102 cfgetospeed

6.103 cfsetispeed

6.104 cfsetospeed

6.105 chdir

6.106 chmod

6.107 chown

6.108 cimag

6.109 cimagf

6.110 cimagl

6.111 clearerr

6.112 clock

6.113 clock_getcpuclockid

6.114 clock_getres

6.115 clock_gettime

6.116 clock_nanosleep

6.117 clock_settime

6.118 clog

6.119 clogf

6.120 clogl

6.121 close

6.122 closedir

6.123 closelog

6.124 confstr

6.125 conj

6.126 conjf

6.127 conjl

6.128 connect

6.129 copysign

6.130 copysignf

6.131 copysignl

6.132 cos

6.133 cosf

6.134 cosh

6.135 coshf

6.136 coshl

6.137 cosl

6.138 cpow

6.139 cpowf

6.140 cpowl

6.141 cproj

6.142 cprojf

6.143 cprojl

6.144 creal

6.145 crealf

6.146 creall

6.147 creat

6.148 crypt

6.149 csin

6.150 csinf

6.151 csinh

6.152 csinhf

6.153 csinhl

6.154 csinl

6.155 csqrt

6.156 csqrtf

6.157 csqrtl

6.158 ctan

6.159 ctanf

6.160 ctanh

6.161 ctanhf

6.162 ctanhl

6.163 ctanl

6.164 ctermid

6.165 ctime

A more flexible function is strftime. However, note that it is locale dependent.

6.166 ctime_r

ctime_r takes a pre-allocated buffer and length of the buffer, and returns NULL on errors. The input buffer should be at least 26 bytes in size. The output string is locale-independent. However, years can have more than 4 digits if time_t is sufficiently wide, so the length of the required output buffer is not easy to determine. Increasing the buffer size when ctime_r returns NULL is not necessarily sufficient. The NULL return value could mean some other error condition, which will not go away by increasing the buffer size.

A more flexible function is strftime. However, note that it is locale dependent.

6.167 daylight

6.168 dbm_clearerr

6.169 dbm_close

6.170 dbm_delete

6.171 dbm_error

6.172 dbm_fetch

6.173 dbm_firstkey

6.174 dbm_nextkey

6.175 dbm_open

6.176 dbm_store

6.177 difftime

6.178 dirfd

With the dirfd module, this functions always sets errno when it fails. (POSIX does not require that dirfd sets errno when it fails.)

6.179 dirname

The Gnulib module dirname provides similar API that also works with Windows file names.

6.180 div

6.181 dlclose

6.182 dlerror

6.183 dlopen

6.184 dlsym

6.185 dprintf

Portability problems fixed by either Gnulib module dprintf or dprintf-posix:

6.186 drand48

6.187 dup

6.188 dup2

6.189 duplocale

6.190 encrypt

6.191 endgrent

6.192 endhostent

6.193 endnetent

6.194 endprotoent

6.195 endpwent

6.196 endservent

6.197 endutxent

6.198 environ

6.199 erand48

6.200 erf

6.201 erfc

6.202 erfcf

6.203 erfcl

6.204 erff

6.205 erfl

6.206 errno

6.207 execl

6.208 execle

6.209 execlp

6.210 execv

6.211 execve

6.212 execvp

6.213 exit

6.214 exp

6.215 exp2

6.216 exp2f

6.217 exp2l

6.218 expf

6.219 expl

6.220 expm1

6.221 expm1f

6.222 expm1l

6.223 fabs

6.224 fabsf

6.225 fabsl

6.226 faccessat

6.227 fattach

6.228 fchdir

6.229 fchmod

6.230 fchmodat

6.231 fchown

6.232 fchownat

6.233 fclose

6.234 fcntl

6.235 fdatasync

6.236 fdetach

6.237 fdim

6.238 fdimf

6.239 fdiml

6.240 fdopen

6.241 fdopendir

6.242 feclearexcept

6.243 fegetenv

6.244 fegetexceptflag

6.245 fegetround

6.246 feholdexcept

6.247 feof

6.248 feraiseexcept

6.249 ferror

6.250 fesetenv

6.251 fesetexceptflag

6.252 fesetround

6.253 fetestexcept

6.254 feupdateenv

6.255 fexecve

6.256 fflush

6.257 ffs

6.258 fgetc

6.259 fgetpos

6.260 fgets

6.261 fgetwc

6.262 fgetws

6.263 fileno

6.264 flockfile

6.265 floor

6.266 floorf

6.267 floorl

6.268 fma

6.269 fmaf

6.270 fmal

6.271 fmax

6.272 fmaxf

6.273 fmaxl

6.274 fmemopen

6.275 fmin

6.276 fminf

6.277 fminl

6.278 fmod

6.279 fmodf

6.280 fmodl

6.281 fmtmsg

6.282 fnmatch

6.283 fopen

6.284 fork

6.285 fpathconf

6.286 fpclassify

6.287 fprintf

Portability problems fixed by Gnulib module stdio or fprintf-posix, together with module sigpipe:

6.288 fputc

6.289 fputs

6.290 fputwc

6.291 fputws

6.292 fread

6.293 free

6.294 freeaddrinfo

6.295 freelocale

6.296 freopen

6.297 frexp

6.298 frexpf

6.299 frexpl

6.300 fscanf

6.301 fseek

6.302 fseeko

6.303 fsetpos

6.304 fstat

6.305 fstatat

6.306 fstatvfs

6.307 fsync

6.308 ftell

6.309 ftello

6.310 ftok

6.311 ftruncate

6.312 ftrylockfile

6.313 ftw

6.314 funlockfile

6.315 futimens

6.316 fwide

6.317 fwprintf

6.318 fwrite

6.319 fwscanf

6.320 gai_strerror

6.321 getaddrinfo

6.322 getc

6.323 getc_unlocked

6.324 getchar

6.325 getchar_unlocked

6.326 getcwd

6.327 getdate

Gnulib provides a module getdate that contains a function get_date that has similar functionality as the getdate function.

6.328 getdate_err

6.329 getdelim

6.330 getegid

6.331 getenv

6.332 geteuid

6.333 getgid

6.334 getgrent

6.335 getgrgid

6.336 getgrgid_r

6.337 getgrnam

6.338 getgrnam_r

6.339 getgroups

6.340 gethostent

6.341 gethostid

6.342 gethostname

6.343 getitimer

6.344 getline

6.345 getlogin

6.346 getlogin_r

6.347 getmsg

6.348 getnameinfo

6.349 getnetbyaddr

6.350 getnetbyname

6.351 getnetent

6.352 getopt

Gnulib provides a module getopt that has support for “long options”. Compared to POSIX, it adds a header file <getopt.h> and functions getopt_long and getopt_long_only.

6.353 getpeername

6.354 getpgid

6.355 getpgrp

6.356 getpid

6.357 getpmsg

6.358 getppid

6.359 getpriority

6.360 getprotobyname

6.361 getprotobynumber

6.362 getprotoent

6.363 getpwent

6.364 getpwnam

6.365 getpwnam_r

6.366 getpwuid

6.367 getpwuid_r

6.368 getrlimit

6.369 getrusage

6.370 gets

6.371 getservbyname

6.372 getservbyport

6.373 getservent

6.374 getsid

6.375 getsockname

6.376 getsockopt

6.377 getsubopt

6.378 gettimeofday

6.379 getuid

6.380 getutxent

6.381 getutxid

6.382 getutxline

6.383 getwc

6.384 getwchar

6.385 glob

6.386 globfree

6.387 gmtime

6.388 gmtime_r

6.389 grantpt

6.390 hcreate

6.391 hdestroy

6.392 hsearch

6.393 htonl

6.394 htons

6.395 hypot

6.396 hypotf

6.397 hypotl

6.398 iconv

6.399 iconv_close

6.400 iconv_open

6.401 if_freenameindex

6.402 if_indextoname

6.403 if_nameindex

6.404 if_nametoindex

6.405 ilogb

6.406 ilogbf

6.407 ilogbl

6.408 imaxabs

6.409 imaxdiv

6.410 inet_addr

6.411 inet_ntoa

Note: inet_ntoa is specific for IPv4 addresses. A protocol independent function is inet_ntop.

6.412 inet_ntop

6.413 inet_pton

6.414 initstate

6.415 insque

6.416 ioctl

6.417 isalnum

6.418 isalnum_l

6.419 isalpha

6.420 isalpha_l

6.421 isascii

6.422 isastream

6.423 isatty

6.424 isblank

6.425 isblank_l

6.426 iscntrl

6.427 iscntrl_l

6.428 isdigit

6.429 isdigit_l

6.430 isfinite

6.431 isgraph

6.432 isgraph_l

6.433 isgreater

6.434 isgreaterequal

6.435 isinf

6.436 isless

6.437 islessequal

6.438 islessgreater

6.439 islower

6.440 islower_l

6.441 isnan

6.442 isnormal

6.443 isprint

6.444 isprint_l

6.445 ispunct

6.446 ispunct_l

6.447 isspace

6.448 isspace_l

6.449 isunordered

6.450 isupper

6.451 isupper_l

6.452 iswalnum

6.453 iswalnum_l

6.454 iswalpha

6.455 iswalpha_l

6.456 iswblank

6.457 iswblank_l

6.458 iswcntrl

6.459 iswcntrl_l

6.460 iswctype

6.461 iswctype_l

6.462 iswdigit

6.463 iswdigit_l

6.464 iswgraph

6.465 iswgraph_l

6.466 iswlower

6.467 iswlower_l

6.468 iswprint

6.469 iswprint_l

6.470 iswpunct

6.471 iswpunct_l

6.472 iswspace

6.473 iswspace_l

6.474 iswupper

6.475 iswupper_l

6.476 iswxdigit

6.477 iswxdigit_l

6.478 isxdigit

6.479 isxdigit_l

6.480 j0

6.481 j1

6.482 jn

6.483 jrand48

6.484 kill

6.485 killpg

6.486 l64a

6.487 labs

6.488 lchown

6.489 lcong48

6.490 ldexp

6.491 ldexpf

6.492 ldexpl

6.493 ldiv

6.494 lfind

6.495 lgamma

6.496 lgammaf

6.497 lgammal

6.498 link

6.499 linkat

6.500 lio_listio

6.501 listen

6.502 llabs

6.503 lldiv

6.504 llrint

6.505 llrintf

6.506 llrintl

6.507 llround

6.508 llroundf

6.509 llroundl

6.510 localeconv

6.511 localtime

6.512 localtime_r

6.513 lockf

6.514 log

6.515 log10

6.516 log10f

6.517 log10l

6.518 log1p

6.519 log1pf

6.520 log1pl

6.521 log2

6.522 log2f

6.523 log2l

6.524 logb

6.525 logbf

6.526 logbl

6.527 logf

6.528 logl

6.529 longjmp

6.530 lrand48

6.531 lrint

6.532 lrintf

6.533 lrintl

6.534 lround

6.535 lroundf

6.536 lroundl

6.537 lsearch

6.538 lseek

6.539 lstat

6.540 malloc

Extension: Gnulib provides a module ‘malloc’ that substitutes a malloc implementation that behaves more like the glibc implementation, regarding the result of malloc (0).

6.541 mblen

6.542 mbrlen

6.543 mbrtowc

6.544 mbsinit

6.545 mbsnrtowcs

6.546 mbsrtowcs

6.547 mbstowcs

6.548 mbtowc

6.549 memccpy

6.550 memchr

6.551 memcmp

6.552 memcpy

6.553 memmove

6.554 memset

6.555 mkdir

6.556 mkdirat

6.557 mkdtemp

6.558 mkfifo

6.559 mkfifoat

6.560 mknod

6.561 mknodat

6.562 mkstemp

6.563 mktime

6.564 mlock

6.565 mlockall

6.566 mmap

6.567 modf

6.568 modff

6.569 modfl

6.570 mprotect

6.571 mq_close

6.572 mq_getattr

6.573 mq_notify

6.574 mq_open

6.575 mq_receive

6.576 mq_send

6.577 mq_setattr

6.578 mq_timedreceive

6.579 mq_timedsend

6.580 mq_unlink

6.581 mrand48

6.582 msgctl

6.583 msgget

6.584 msgrcv

6.585 msgsnd

6.586 msync

6.587 munlock

6.588 munlockall

6.589 munmap

6.590 nan

6.591 nanf

6.592 nanl

6.593 nanosleep

6.594 nearbyint

6.595 nearbyintf

6.596 nearbyintl

6.597 newlocale

6.598 nextafter

6.599 nextafterf

6.600 nextafterl

6.601 nexttoward

6.602 nexttowardf

6.603 nexttowardl

6.604 nftw

6.605 nice

6.606 nl_langinfo

6.607 nl_langinfo_l

6.608 nrand48

6.609 ntohl

6.610 ntohs

6.611 open

6.612 openat

6.613 opendir

6.614 openlog

6.615 open_memstream

6.616 open_wmemstream

6.617 optarg

6.618 opterr

6.619 optind

6.620 optopt

6.621 pathconf

6.622 pause

6.623 pclose

6.624 perror

6.625 pipe

6.626 poll

6.627 popen

6.628 posix_fadvise

6.629 posix_fallocate

6.630 posix_madvise

6.631 posix_mem_offset

6.632 posix_memalign

6.633 posix_openpt

6.634 posix_spawn

6.635 posix_spawn_file_actions_addclose

6.636 posix_spawn_file_actions_adddup2

6.637 posix_spawn_file_actions_addopen

6.638 posix_spawn_file_actions_destroy

6.639 posix_spawn_file_actions_init

6.640 posix_spawnattr_destroy

6.641 posix_spawnattr_getflags

6.642 posix_spawnattr_getpgroup

6.643 posix_spawnattr_getschedparam

6.644 posix_spawnattr_getschedpolicy

6.645 posix_spawnattr_getsigdefault

6.646 posix_spawnattr_getsigmask

6.647 posix_spawnattr_init

6.648 posix_spawnattr_setflags

6.649 posix_spawnattr_setpgroup

6.650 posix_spawnattr_setschedparam

6.651 posix_spawnattr_setschedpolicy

6.652 posix_spawnattr_setsigdefault

6.653 posix_spawnattr_setsigmask

6.654 posix_spawnp

6.655 posix_trace_attr_destroy

6.656 posix_trace_attr_getclockres

6.657 posix_trace_attr_getcreatetime

6.658 posix_trace_attr_getgenversion

6.659 posix_trace_attr_getinherited

6.660 posix_trace_attr_getlogfullpolicy

6.661 posix_trace_attr_getlogsize

6.662 posix_trace_attr_getmaxdatasize

6.663 posix_trace_attr_getmaxsystemeventsize

6.664 posix_trace_attr_getmaxusereventsize

6.665 posix_trace_attr_getname

6.666 posix_trace_attr_getstreamfullpolicy

6.667 posix_trace_attr_getstreamsize

6.668 posix_trace_attr_init

6.669 posix_trace_attr_setinherited

6.670 posix_trace_attr_setlogfullpolicy

6.671 posix_trace_attr_setlogsize

6.672 posix_trace_attr_setmaxdatasize

6.673 posix_trace_attr_setname

6.674 posix_trace_attr_setstreamfullpolicy

6.675 posix_trace_attr_setstreamsize

6.676 posix_trace_clear

6.677 posix_trace_close

6.678 posix_trace_create

6.679 posix_trace_create_withlog

6.680 posix_trace_event

6.681 posix_trace_eventid_equal

6.682 posix_trace_eventid_get_name

6.683 posix_trace_eventid_open

6.684 posix_trace_eventset_add

6.685 posix_trace_eventset_del

6.686 posix_trace_eventset_empty

6.687 posix_trace_eventset_fill

6.688 posix_trace_eventset_ismember

6.689 posix_trace_eventtypelist_getnext_id

6.690 posix_trace_eventtypelist_rewind

6.691 posix_trace_flush

6.692 posix_trace_get_attr

6.693 posix_trace_get_filter

6.694 posix_trace_get_status

6.695 posix_trace_getnext_event

6.696 posix_trace_open

6.697 posix_trace_rewind

6.698 posix_trace_set_filter

6.699 posix_trace_shutdown

6.700 posix_trace_start

6.701 posix_trace_stop

6.702 posix_trace_timedgetnext_event

6.703 posix_trace_trid_eventid_open

6.704 posix_trace_trygetnext_event

6.705 posix_typed_mem_get_info

6.706 posix_typed_mem_open

6.707 pow

6.708 powf

6.709 powl

6.710 pread

6.711 printf

Portability problems fixed by Gnulib module stdio or printf-posix, together with module sigpipe:

GNU Gnulib

Table of Contents

GNU Gnulib

1 Introduction

1.1 Benefits of using Gnulib

1.2 Library vs. Reusable Code

1.3 Portability and Application Code

1.4 Modules

1.5 Various Kinds of Modules

1.5.1 Support for ISO C or POSIX functions.

1.5.2 Enhancements of ISO C or POSIX functions

1.5.3 Portable general use facilities

1.5.4 Reusable application code

1.5.5 Object oriented classes

1.5.6 Interfaces to external libraries

1.5.7 Build / maintenance infrastructure

1.6 Collaborative Development

1.7 Copyright

1.8 Steady Development

1.9 Openness

2 Invoking gnulib-tool

2.1 Initial import

2.2 Modified imports

2.3 Simple update

2.4 Changing your sources for use with Gnulib

2.5 Caveat: gettextize and autopoint users

2.6 Handling Gnulib's own message translations

2.7 Issues with Version Control Systems

2.8 Bundling the unit tests of the Gnulib modules

3 Miscellaneous Notes

3.1 Comments

3.2 Header files

Include ordering

3.3 Out of memory handling

3.4 Obsolete modules

3.5 Library version handling

3.6 Windows sockets

3.6.1 Getaddrinfo and WINVER

3.7 Libtool and Windows

3.8 License Texinfo sources

3.9 Build robot for gnulib

4 Building the ISO C and POSIX Substitutes

5 ISO C and POSIX Header File Substitutes

5.1 aio.h

5.2 arpa/inet.h

5.3 assert.h

5.4 complex.h

5.5 cpio.h

5.6 ctype.h

5.7 dirent.h

5.8 dlfcn.h

5.9 errno.h

5.10 fcntl.h

5.11 fenv.h

5.12 float.h

5.13 fmtmsg.h

5.14 fnmatch.h

5.15 ftw.h

5.16 glob.h

5.17 grp.h

5.18 iconv.h

5.19 inttypes.h

5.20 iso646.h

5.21 langinfo.h

5.22 libgen.h

5.23 limits.h

5.24 locale.h

5.25 math.h

5.26 monetary.h

5.27 mqueue.h

5.28 ndbm.h

5.29 net/if.h

5.30 netdb.h

5.31 netinet/in.h

5.32 netinet/tcp.h

5.33 nl_types.h

5.34 poll.h

5.35 pthread.h

5.36 pwd.h

5.37 regex.h

2.5 Caveat: `gettextize` and `autopoint` users

5.1 `aio.h`

5.2 `arpa/inet.h`

5.3 `assert.h`

5.4 `complex.h`

5.5 `cpio.h`

5.6 `ctype.h`

5.7 `dirent.h`

5.8 `dlfcn.h`

5.9 `errno.h`

5.10 `fcntl.h`

5.11 `fenv.h`

5.12 `float.h`

5.13 `fmtmsg.h`

5.14 `fnmatch.h`

5.15 `ftw.h`

5.16 `glob.h`

5.17 `grp.h`

5.18 `iconv.h`

5.19 `inttypes.h`

5.20 `iso646.h`

5.21 `langinfo.h`

5.22 `libgen.h`

5.23 `limits.h`

5.24 `locale.h`

5.25 `math.h`

5.26 `monetary.h`

5.27 `mqueue.h`

5.28 `ndbm.h`

5.29 `net/if.h`

5.30 `netdb.h`

5.31 `netinet/in.h`

5.32 `netinet/tcp.h`

5.33 `nl_types.h`

5.34 `poll.h`

5.35 `pthread.h`

5.36 `pwd.h`

5.37 `regex.h`

5.38 `sched.h`

5.39 `search.h`

5.40 `semaphore.h`

5.41 `setjmp.h`

5.42 `signal.h`

5.43 `spawn.h`

5.44 `stdarg.h`

5.45 `stdbool.h`

5.46 `stddef.h`

5.47 `stdint.h`

5.48 `stdio.h`

5.49 `stdlib.h`

5.50 `string.h`

5.51 `strings.h`

5.52 `stropts.h`

5.53 `sys/ipc.h`

5.54 `sys/mman.h`

5.55 `sys/msg.h`

5.56 `sys/resource.h`

5.57 `sys/select.h`

5.58 `sys/sem.h`

5.59 `sys/shm.h`

5.60 `sys/socket.h`

5.61 `sys/stat.h`

5.62 `sys/statvfs.h`

5.63 `sys/time.h`

5.64 `sys/timeb.h`

5.65 `sys/times.h`

5.66 `sys/types.h`

5.67 `sys/uio.h`

5.68 `sys/un.h`

5.69 `sys/utsname.h`

5.70 `sys/wait.h`

5.71 `syslog.h`

5.72 `tar.h`

5.73 `termios.h`

5.74 `tgmath.h`

5.75 `time.h`

5.76 `trace.h`

5.77 `ucontext.h`

5.78 `ulimit.h`

5.79 `unistd.h`