]>
Commit | Line | Data |
---|---|---|
1 | Installing the GNU C Library | |
2 | **************************** | |
3 | ||
4 | Before you do anything else, you should read the FAQ at | |
5 | <http://sourceware.org/glibc/wiki/FAQ>. It answers common questions and | |
6 | describes problems you may experience with compilation and installation. | |
7 | ||
8 | Features can be added to the GNU C Library via "add-on" bundles. | |
9 | These are separate tar files, which you unpack into the top level of the | |
10 | source tree. Then you give 'configure' the '--enable-add-ons' option to | |
11 | activate them, and they will be compiled into the library. | |
12 | ||
13 | You will need recent versions of several GNU tools: definitely GCC | |
14 | and GNU Make, and possibly others. *Note Tools for Compilation::, | |
15 | below. | |
16 | ||
17 | Configuring and compiling the GNU C Library | |
18 | =========================================== | |
19 | ||
20 | The GNU C Library cannot be compiled in the source directory. You must | |
21 | build it in a separate build directory. For example, if you have | |
22 | unpacked the GNU C Library sources in '/src/gnu/glibc-VERSION', create a | |
23 | directory '/src/gnu/glibc-build' to put the object files in. This | |
24 | allows removing the whole build directory in case an error occurs, which | |
25 | is the safest way to get a fresh start and should always be done. | |
26 | ||
27 | From your object directory, run the shell script 'configure' located | |
28 | at the top level of the source tree. In the scenario above, you'd type | |
29 | ||
30 | $ ../glibc-VERSION/configure ARGS... | |
31 | ||
32 | Please note that even though you're building in a separate build | |
33 | directory, the compilation may need to create or modify files and | |
34 | directories in the source directory. | |
35 | ||
36 | 'configure' takes many options, but the only one that is usually | |
37 | mandatory is '--prefix'. This option tells 'configure' where you want | |
38 | the GNU C Library installed. This defaults to '/usr/local', but the | |
39 | normal setting to install as the standard system library is | |
40 | '--prefix=/usr' for GNU/Linux systems and '--prefix=' (an empty prefix) | |
41 | for GNU/Hurd systems. | |
42 | ||
43 | It may also be useful to set the CC and CFLAGS variables in the | |
44 | environment when running 'configure'. CC selects the C compiler that | |
45 | will be used, and CFLAGS sets optimization options for the compiler. | |
46 | ||
47 | The following list describes all of the available options for | |
48 | 'configure': | |
49 | ||
50 | '--prefix=DIRECTORY' | |
51 | Install machine-independent data files in subdirectories of | |
52 | 'DIRECTORY'. The default is to install in '/usr/local'. | |
53 | ||
54 | '--exec-prefix=DIRECTORY' | |
55 | Install the library and other machine-dependent files in | |
56 | subdirectories of 'DIRECTORY'. The default is to the '--prefix' | |
57 | directory if that option is specified, or '/usr/local' otherwise. | |
58 | ||
59 | '--with-headers=DIRECTORY' | |
60 | Look for kernel header files in DIRECTORY, not '/usr/include'. The | |
61 | GNU C Library needs information from the kernel's header files | |
62 | describing the interface to the kernel. The GNU C Library will | |
63 | normally look in '/usr/include' for them, but if you specify this | |
64 | option, it will look in DIRECTORY instead. | |
65 | ||
66 | This option is primarily of use on a system where the headers in | |
67 | '/usr/include' come from an older version of the GNU C Library. | |
68 | Conflicts can occasionally happen in this case. You can also use | |
69 | this option if you want to compile the GNU C Library with a newer | |
70 | set of kernel headers than the ones found in '/usr/include'. | |
71 | ||
72 | '--enable-add-ons[=LIST]' | |
73 | Specify add-on packages to include in the build. If this option is | |
74 | specified with no list, it enables all the add-on packages it finds | |
75 | in the main source directory; this is the default behavior. You | |
76 | may specify an explicit list of add-ons to use in LIST, separated | |
77 | by spaces or commas (if you use spaces, remember to quote them from | |
78 | the shell). Each add-on in LIST can be an absolute directory name | |
79 | or can be a directory name relative to the main source directory, | |
80 | or relative to the build directory (that is, the current working | |
81 | directory). For example, | |
82 | '--enable-add-ons=nptl,../glibc-libidn-VERSION'. | |
83 | ||
84 | '--enable-kernel=VERSION' | |
85 | This option is currently only useful on GNU/Linux systems. The | |
86 | VERSION parameter should have the form X.Y.Z and describes the | |
87 | smallest version of the Linux kernel the generated library is | |
88 | expected to support. The higher the VERSION number is, the less | |
89 | compatibility code is added, and the faster the code gets. | |
90 | ||
91 | '--with-binutils=DIRECTORY' | |
92 | Use the binutils (assembler and linker) in 'DIRECTORY', not the | |
93 | ones the C compiler would default to. You can use this option if | |
94 | the default binutils on your system cannot deal with all the | |
95 | constructs in the GNU C Library. In that case, 'configure' will | |
96 | detect the problem and suppress these constructs, so that the | |
97 | library will still be usable, but functionality may be lost--for | |
98 | example, you can't build a shared libc with old binutils. | |
99 | ||
100 | '--without-fp' | |
101 | Use this option if your computer lacks hardware floating-point | |
102 | support and your operating system does not emulate an FPU. | |
103 | ||
104 | '--disable-shared' | |
105 | Don't build shared libraries even if it is possible. Not all | |
106 | systems support shared libraries; you need ELF support and | |
107 | (currently) the GNU linker. | |
108 | ||
109 | '--disable-profile' | |
110 | Don't build libraries with profiling information. You may want to | |
111 | use this option if you don't plan to do profiling. | |
112 | ||
113 | '--enable-static-nss' | |
114 | Compile static versions of the NSS (Name Service Switch) libraries. | |
115 | This is not recommended because it defeats the purpose of NSS; a | |
116 | program linked statically with the NSS libraries cannot be | |
117 | dynamically reconfigured to use a different name database. | |
118 | ||
119 | '--without-tls' | |
120 | By default the C library is built with support for thread-local | |
121 | storage if the used tools support it. By using '--without-tls' | |
122 | this can be prevented though there generally is no reason since it | |
123 | creates compatibility problems. | |
124 | ||
125 | '--enable-hardcoded-path-in-tests' | |
126 | By default, dynamic tests are linked to run with the installed C | |
127 | library. This option hardcodes the newly built C library path in | |
128 | dynamic tests so that they can be invoked directly. | |
129 | ||
130 | '--enable-lock-elision=yes' | |
131 | Enable lock elision for pthread mutexes by default. | |
132 | ||
133 | '--enable-pt_chown' | |
134 | The file 'pt_chown' is a helper binary for 'grantpt' (*note | |
135 | Pseudo-Terminals: Allocation.) that is installed setuid root to fix | |
136 | up pseudo-terminal ownership. It is not built by default because | |
137 | systems using the Linux kernel are commonly built with the 'devpts' | |
138 | filesystem enabled and mounted at '/dev/pts', which manages | |
139 | pseudo-terminal ownership automatically. By using | |
140 | '--enable-pt_chown', you may build 'pt_chown' and install it setuid | |
141 | and owned by 'root'. The use of 'pt_chown' introduces additional | |
142 | security risks to the system and you should enable it only if you | |
143 | understand and accept those risks. | |
144 | ||
145 | '--disable-werror' | |
146 | By default, the GNU C Library is built with '-Werror'. If you wish | |
147 | to build without this option (for example, if building with a newer | |
148 | version of GCC than this version of the GNU C Library was tested | |
149 | with, so new warnings cause the build with '-Werror' to fail), you | |
150 | can configure with '--disable-werror'. | |
151 | ||
152 | '--build=BUILD-SYSTEM' | |
153 | '--host=HOST-SYSTEM' | |
154 | These options are for cross-compiling. If you specify both options | |
155 | and BUILD-SYSTEM is different from HOST-SYSTEM, 'configure' will | |
156 | prepare to cross-compile the GNU C Library from BUILD-SYSTEM to be | |
157 | used on HOST-SYSTEM. You'll probably need the '--with-headers' | |
158 | option too, and you may have to override CONFIGURE's selection of | |
159 | the compiler and/or binutils. | |
160 | ||
161 | If you only specify '--host', 'configure' will prepare for a native | |
162 | compile but use what you specify instead of guessing what your | |
163 | system is. This is most useful to change the CPU submodel. For | |
164 | example, if 'configure' guesses your machine as 'i686-pc-linux-gnu' | |
165 | but you want to compile a library for 586es, give | |
166 | '--host=i586-pc-linux-gnu' or just '--host=i586-linux' and add the | |
167 | appropriate compiler flags ('-mcpu=i586' will do the trick) to | |
168 | CFLAGS. | |
169 | ||
170 | If you specify just '--build', 'configure' will get confused. | |
171 | ||
172 | '--with-pkgversion=VERSION' | |
173 | Specify a description, possibly including a build number or build | |
174 | date, of the binaries being built, to be included in '--version' | |
175 | output from programs installed with the GNU C Library. For | |
176 | example, '--with-pkgversion='FooBar GNU/Linux glibc build 123''. | |
177 | The default value is 'GNU libc'. | |
178 | ||
179 | '--with-bugurl=URL' | |
180 | Specify the URL that users should visit if they wish to report a | |
181 | bug, to be included in '--help' output from programs installed with | |
182 | the GNU C Library. The default value refers to the main | |
183 | bug-reporting information for the GNU C Library. | |
184 | ||
185 | To build the library and related programs, type 'make'. This will | |
186 | produce a lot of output, some of which may look like errors from 'make' | |
187 | but isn't. Look for error messages from 'make' containing '***'. Those | |
188 | indicate that something is seriously wrong. | |
189 | ||
190 | The compilation process can take a long time, depending on the | |
191 | configuration and the speed of your machine. Some complex modules may | |
192 | take a very long time to compile, as much as several minutes on slower | |
193 | machines. Do not panic if the compiler appears to hang. | |
194 | ||
195 | If you want to run a parallel make, simply pass the '-j' option with | |
196 | an appropriate numeric parameter to 'make'. You need a recent GNU | |
197 | 'make' version, though. | |
198 | ||
199 | To build and run test programs which exercise some of the library | |
200 | facilities, type 'make check'. If it does not complete successfully, do | |
201 | not use the built library, and report a bug after verifying that the | |
202 | problem is not already known. *Note Reporting Bugs::, for instructions | |
203 | on reporting bugs. Note that some of the tests assume they are not | |
204 | being run by 'root'. We recommend you compile and test the GNU C | |
205 | Library as an unprivileged user. | |
206 | ||
207 | Before reporting bugs make sure there is no problem with your system. | |
208 | The tests (and later installation) use some pre-existing files of the | |
209 | system such as '/etc/passwd', '/etc/nsswitch.conf' and others. These | |
210 | files must all contain correct and sensible content. | |
211 | ||
212 | Normally, 'make check' will run all the tests before reporting all | |
213 | problems found and exiting with error status if any problems occurred. | |
214 | You can specify 'stop-on-test-failure=y' when running 'make check' to | |
215 | make the test run stop and exit with an error status immediately when a | |
216 | failure occurs. | |
217 | ||
218 | To format the 'GNU C Library Reference Manual' for printing, type | |
219 | 'make dvi'. You need a working TeX installation to do this. The | |
220 | distribution builds the on-line formatted version of the manual, as Info | |
221 | files, as part of the build process. You can build them manually with | |
222 | 'make info'. | |
223 | ||
224 | The library has a number of special-purpose configuration parameters | |
225 | which you can find in 'Makeconfig'. These can be overwritten with the | |
226 | file 'configparms'. To change them, create a 'configparms' in your | |
227 | build directory and add values as appropriate for your system. The file | |
228 | is included and parsed by 'make' and has to follow the conventions for | |
229 | makefiles. | |
230 | ||
231 | It is easy to configure the GNU C Library for cross-compilation by | |
232 | setting a few variables in 'configparms'. Set 'CC' to the | |
233 | cross-compiler for the target you configured the library for; it is | |
234 | important to use this same 'CC' value when running 'configure', like | |
235 | this: 'CC=TARGET-gcc configure TARGET'. Set 'BUILD_CC' to the compiler | |
236 | to use for programs run on the build system as part of compiling the | |
237 | library. You may need to set 'AR' to cross-compiling versions of 'ar' | |
238 | if the native tools are not configured to work with object files for the | |
239 | target you configured for. When cross-compiling the GNU C Library, it | |
240 | may be tested using 'make check | |
241 | test-wrapper="SRCDIR/scripts/cross-test-ssh.sh HOSTNAME"', where SRCDIR | |
242 | is the absolute directory name for the main source directory and | |
243 | HOSTNAME is the host name of a system that can run the newly built | |
244 | binaries of the GNU C Library. The source and build directories must be | |
245 | visible at the same locations on both the build system and HOSTNAME. | |
246 | ||
247 | In general, when testing the GNU C Library, 'test-wrapper' may be set | |
248 | to the name and arguments of any program to run newly built binaries. | |
249 | This program must preserve the arguments to the binary being run, its | |
250 | working directory and the standard input, output and error file | |
251 | descriptors. If 'TEST-WRAPPER env' will not work to run a program with | |
252 | environment variables set, then 'test-wrapper-env' must be set to a | |
253 | program that runs a newly built program with environment variable | |
254 | assignments in effect, those assignments being specified as 'VAR=VALUE' | |
255 | before the name of the program to be run. If multiple assignments to | |
256 | the same variable are specified, the last assignment specified must take | |
257 | precedence. Similarly, if 'TEST-WRAPPER env -i' will not work to run a | |
258 | program with an environment completely empty of variables except those | |
259 | directly assigned, then 'test-wrapper-env-only' must be set; its use has | |
260 | the same syntax as 'test-wrapper-env', the only difference in its | |
261 | semantics being starting with an empty set of environment variables | |
262 | rather than the ambient set. | |
263 | ||
264 | Installing the C Library | |
265 | ======================== | |
266 | ||
267 | To install the library and its header files, and the Info files of the | |
268 | manual, type 'make install'. This will build things, if necessary, | |
269 | before installing them; however, you should still compile everything | |
270 | first. If you are installing the GNU C Library as your primary C | |
271 | library, we recommend that you shut the system down to single-user mode | |
272 | first, and reboot afterward. This minimizes the risk of breaking things | |
273 | when the library changes out from underneath. | |
274 | ||
275 | 'make install' will do the entire job of upgrading from a previous | |
276 | installation of the GNU C Library version 2.x. There may sometimes be | |
277 | headers left behind from the previous installation, but those are | |
278 | generally harmless. If you want to avoid leaving headers behind you can | |
279 | do things in the following order. | |
280 | ||
281 | You must first build the library ('make'), optionally check it ('make | |
282 | check'), switch the include directories and then install ('make | |
283 | install'). The steps must be done in this order. Not moving the | |
284 | directory before install will result in an unusable mixture of header | |
285 | files from both libraries, but configuring, building, and checking the | |
286 | library requires the ability to compile and run programs against the old | |
287 | library. The new '/usr/include', after switching the include | |
288 | directories and before installing the library should contain the Linux | |
289 | headers, but nothing else. If you do this, you will need to restore any | |
290 | headers from libraries other than the GNU C Library yourself after | |
291 | installing the library. | |
292 | ||
293 | You can install the GNU C Library somewhere other than where you | |
294 | configured it to go by setting the 'install_root' variable on the | |
295 | command line for 'make install'. The value of this variable is | |
296 | prepended to all the paths for installation. This is useful when | |
297 | setting up a chroot environment or preparing a binary distribution. The | |
298 | directory should be specified with an absolute file name. | |
299 | ||
300 | The GNU C Library includes a daemon called 'nscd', which you may or | |
301 | may not want to run. 'nscd' caches name service lookups; it can | |
302 | dramatically improve performance with NIS+, and may help with DNS as | |
303 | well. | |
304 | ||
305 | One auxiliary program, '/usr/libexec/pt_chown', is installed setuid | |
306 | 'root' if the '--enable-pt_chown' configuration option is used. This | |
307 | program is invoked by the 'grantpt' function; it sets the permissions on | |
308 | a pseudoterminal so it can be used by the calling process. If you are | |
309 | using a Linux kernel with the 'devpts' filesystem enabled and mounted at | |
310 | '/dev/pts', you don't need this program. | |
311 | ||
312 | After installation you might want to configure the timezone and | |
313 | locale installation of your system. The GNU C Library comes with a | |
314 | locale database which gets configured with 'localedef'. For example, to | |
315 | set up a German locale with name 'de_DE', simply issue the command | |
316 | 'localedef -i de_DE -f ISO-8859-1 de_DE'. To configure all locales that | |
317 | are supported by the GNU C Library, you can issue from your build | |
318 | directory the command 'make localedata/install-locales'. | |
319 | ||
320 | To configure the locally used timezone, set the 'TZ' environment | |
321 | variable. The script 'tzselect' helps you to select the right value. | |
322 | As an example, for Germany, 'tzselect' would tell you to use | |
323 | 'TZ='Europe/Berlin''. For a system wide installation (the given paths | |
324 | are for an installation with '--prefix=/usr'), link the timezone file | |
325 | which is in '/usr/share/zoneinfo' to the file '/etc/localtime'. For | |
326 | Germany, you might execute 'ln -s /usr/share/zoneinfo/Europe/Berlin | |
327 | /etc/localtime'. | |
328 | ||
329 | Recommended Tools for Compilation | |
330 | ================================= | |
331 | ||
332 | We recommend installing the following GNU tools before attempting to | |
333 | build the GNU C Library: | |
334 | ||
335 | * GNU 'make' 3.79 or newer | |
336 | ||
337 | You need the latest version of GNU 'make'. Modifying the GNU C | |
338 | Library to work with other 'make' programs would be so difficult | |
339 | that we recommend you port GNU 'make' instead. *Really.* We | |
340 | recommend GNU 'make' version 3.79. All earlier versions have | |
341 | severe bugs or lack features. | |
342 | ||
343 | * GCC 4.6 or newer | |
344 | ||
345 | GCC 4.6 or higher is required. In general it is recommended to use | |
346 | the newest version of the compiler that is known to work for | |
347 | building the GNU C Library, as newer compilers usually produce | |
348 | better code. As of release time, GCC 4.9.2 is the newest compiler | |
349 | verified to work to build the GNU C Library. | |
350 | ||
351 | You can use whatever compiler you like to compile programs that use | |
352 | the GNU C Library. | |
353 | ||
354 | Check the FAQ for any special compiler issues on particular | |
355 | platforms. | |
356 | ||
357 | * GNU 'binutils' 2.22 or later | |
358 | ||
359 | You must use GNU 'binutils' (as and ld) to build the GNU C Library. | |
360 | No other assembler or linker has the necessary functionality at the | |
361 | moment. As of release time, GNU 'binutils' 2.25 is the newest | |
362 | verified to work to build the GNU C Library. | |
363 | ||
364 | * GNU 'texinfo' 4.7 or later | |
365 | ||
366 | To correctly translate and install the Texinfo documentation you | |
367 | need this version of the 'texinfo' package. Earlier versions do | |
368 | not understand all the tags used in the document, and the | |
369 | installation mechanism for the info files is not present or works | |
370 | differently. As of release time, 'texinfo' 5.2 is the newest | |
371 | verified to work to build the GNU C Library. | |
372 | ||
373 | * GNU 'awk' 3.1.2, or higher | |
374 | ||
375 | 'awk' is used in several places to generate files. Some 'gawk' | |
376 | extensions are used, including the 'asorti' function, which was | |
377 | introduced in version 3.1.2 of 'gawk'. | |
378 | ||
379 | * Perl 5 | |
380 | ||
381 | Perl is not required, but it is used if present to test the | |
382 | installation. We may decide to use it elsewhere in the future. | |
383 | ||
384 | * GNU 'sed' 3.02 or newer | |
385 | ||
386 | 'Sed' is used in several places to generate files. Most scripts | |
387 | work with any version of 'sed'. The known exception is the script | |
388 | 'po2test.sed' in the 'intl' subdirectory which is used to generate | |
389 | 'msgs.h' for the test suite. This script works correctly only with | |
390 | GNU 'sed' 3.02. If you like to run the test suite, you should | |
391 | definitely upgrade 'sed'. | |
392 | ||
393 | If you change any of the 'configure.ac' files you will also need | |
394 | ||
395 | * GNU 'autoconf' 2.69 (exactly) | |
396 | ||
397 | and if you change any of the message translation files you will need | |
398 | ||
399 | * GNU 'gettext' 0.10.36 or later | |
400 | ||
401 | If you wish to regenerate the 'yacc' parser code in the 'intl' | |
402 | subdirectory you will need | |
403 | ||
404 | * GNU 'bison' 2.7 or later | |
405 | ||
406 | You may also need these packages if you upgrade your source tree using | |
407 | patches, although we try to avoid this. | |
408 | ||
409 | Specific advice for GNU/Linux systems | |
410 | ===================================== | |
411 | ||
412 | If you are installing the GNU C Library on GNU/Linux systems, you need | |
413 | to have the header files from a 2.6.32 or newer kernel around for | |
414 | reference. These headers must be installed using 'make | |
415 | headers_install'; the headers present in the kernel source directory are | |
416 | not suitable for direct use by the GNU C Library. You do not need to | |
417 | use that kernel, just have its headers installed where the GNU C Library | |
418 | can access them, referred to here as INSTALL-DIRECTORY. The easiest way | |
419 | to do this is to unpack it in a directory such as | |
420 | '/usr/src/linux-VERSION'. In that directory, run 'make headers_install | |
421 | INSTALL_HDR_PATH=INSTALL-DIRECTORY'. Finally, configure the GNU C | |
422 | Library with the option '--with-headers=INSTALL-DIRECTORY/include'. Use | |
423 | the most recent kernel you can get your hands on. (If you are | |
424 | cross-compiling the GNU C Library, you need to specify | |
425 | 'ARCH=ARCHITECTURE' in the 'make headers_install' command, where | |
426 | ARCHITECTURE is the architecture name used by the Linux kernel, such as | |
427 | 'x86' or 'powerpc'.) | |
428 | ||
429 | After installing the GNU C Library, you may need to remove or rename | |
430 | directories such as '/usr/include/linux' and '/usr/include/asm', and | |
431 | replace them with copies of directories such as 'linux' and 'asm' from | |
432 | 'INSTALL-DIRECTORY/include'. All directories present in | |
433 | 'INSTALL-DIRECTORY/include' should be copied, except that the GNU C | |
434 | Library provides its own version of '/usr/include/scsi'; the files | |
435 | provided by the kernel should be copied without replacing those provided | |
436 | by the GNU C Library. The 'linux', 'asm' and 'asm-generic' directories | |
437 | are required to compile programs using the GNU C Library; the other | |
438 | directories describe interfaces to the kernel but are not required if | |
439 | not compiling programs using those interfaces. You do not need to copy | |
440 | kernel headers if you did not specify an alternate kernel header source | |
441 | using '--with-headers'. | |
442 | ||
443 | The Filesystem Hierarchy Standard for GNU/Linux systems expects some | |
444 | components of the GNU C Library installation to be in '/lib' and some in | |
445 | '/usr/lib'. This is handled automatically if you configure the GNU C | |
446 | Library with '--prefix=/usr'. If you set some other prefix or allow it | |
447 | to default to '/usr/local', then all the components are installed there. | |
448 | ||
449 | Reporting Bugs | |
450 | ============== | |
451 | ||
452 | There are probably bugs in the GNU C Library. There are certainly | |
453 | errors and omissions in this manual. If you report them, they will get | |
454 | fixed. If you don't, no one will ever know about them and they will | |
455 | remain unfixed for all eternity, if not longer. | |
456 | ||
457 | It is a good idea to verify that the problem has not already been | |
458 | reported. Bugs are documented in two places: The file 'BUGS' describes | |
459 | a number of well known bugs and the central GNU C Library bug tracking | |
460 | system has a WWW interface at <http://sourceware.org/bugzilla/>. The | |
461 | WWW interface gives you access to open and closed reports. A closed | |
462 | report normally includes a patch or a hint on solving the problem. | |
463 | ||
464 | To report a bug, first you must find it. With any luck, this will be | |
465 | the hard part. Once you've found a bug, make sure it's really a bug. A | |
466 | good way to do this is to see if the GNU C Library behaves the same way | |
467 | some other C library does. If so, probably you are wrong and the | |
468 | libraries are right (but not necessarily). If not, one of the libraries | |
469 | is probably wrong. It might not be the GNU C Library. Many historical | |
470 | Unix C libraries permit things that we don't, such as closing a file | |
471 | twice. | |
472 | ||
473 | If you think you have found some way in which the GNU C Library does | |
474 | not conform to the ISO and POSIX standards (*note Standards and | |
475 | Portability::), that is definitely a bug. Report it! | |
476 | ||
477 | Once you're sure you've found a bug, try to narrow it down to the | |
478 | smallest test case that reproduces the problem. In the case of a C | |
479 | library, you really only need to narrow it down to one library function | |
480 | call, if possible. This should not be too difficult. | |
481 | ||
482 | The final step when you have a simple test case is to report the bug. | |
483 | Do this at <http://www.gnu.org/software/libc/bugs.html>. | |
484 | ||
485 | If you are not sure how a function should behave, and this manual | |
486 | doesn't tell you, that's a bug in the manual. Report that too! If the | |
487 | function's behavior disagrees with the manual, then either the library | |
488 | or the manual has a bug, so report the disagreement. If you find any | |
489 | errors or omissions in this manual, please report them to the bug | |
490 | database. If you refer to specific sections of the manual, please | |
491 | include the section names for easier identification. |