]>
Commit | Line | Data |
---|---|---|
1 | Installing the GNU C Library | |
2 | **************************** | |
3 | ||
4 | Before you do anything else, you should read the FAQ at | |
5 | <https://sourceware.org/glibc/wiki/FAQ>. It answers common questions | |
6 | and describes problems you may experience with compilation and | |
7 | installation. | |
8 | ||
9 | You will need recent versions of several GNU tools: definitely GCC | |
10 | and GNU Make, and possibly others. *Note Tools for Compilation::, | |
11 | below. | |
12 | ||
13 | Configuring and compiling the GNU C Library | |
14 | =========================================== | |
15 | ||
16 | The GNU C Library cannot be compiled in the source directory. You must | |
17 | build it in a separate build directory. For example, if you have | |
18 | unpacked the GNU C Library sources in ‘/src/gnu/glibc-VERSION’, create a | |
19 | directory ‘/src/gnu/glibc-build’ to put the object files in. This | |
20 | allows removing the whole build directory in case an error occurs, which | |
21 | is the safest way to get a fresh start and should always be done. | |
22 | ||
23 | From your object directory, run the shell script ‘configure’ located | |
24 | at the top level of the source tree. In the scenario above, you’d type | |
25 | ||
26 | $ ../glibc-VERSION/configure ARGS... | |
27 | ||
28 | Please note that even though you’re building in a separate build | |
29 | directory, the compilation may need to create or modify files and | |
30 | directories in the source directory. | |
31 | ||
32 | ‘configure’ takes many options, but the only one that is usually | |
33 | mandatory is ‘--prefix’. This option tells ‘configure’ where you want | |
34 | the GNU C Library installed. This defaults to ‘/usr/local’, but the | |
35 | normal setting to install as the standard system library is | |
36 | ‘--prefix=/usr’ for GNU/Linux systems and ‘--prefix=’ (an empty prefix) | |
37 | for GNU/Hurd systems. | |
38 | ||
39 | It may also be useful to pass ‘CC=COMPILER’ and ‘CFLAGS=FLAGS’ | |
40 | arguments to ‘configure’. ‘CC’ selects the C compiler that will be | |
41 | used, and ‘CFLAGS’ sets optimization options for the compiler. Any | |
42 | compiler options required for all compilations, such as options | |
43 | selecting an ABI or a processor for which to generate code, should be | |
44 | included in ‘CC’. Options that may be overridden by the GNU C Library | |
45 | build system for particular files, such as for optimization and | |
46 | debugging, should go in ‘CFLAGS’. The default value of ‘CFLAGS’ is ‘-g | |
47 | -O2’, and the GNU C Library cannot be compiled without optimization, so | |
48 | if ‘CFLAGS’ is specified it must enable optimization. For example: | |
49 | ||
50 | $ ../glibc-VERSION/configure CC="gcc -m32" CFLAGS="-O3" | |
51 | ||
52 | The following list describes all of the available options for | |
53 | ‘configure’: | |
54 | ||
55 | ‘--prefix=DIRECTORY’ | |
56 | Install machine-independent data files in subdirectories of | |
57 | ‘DIRECTORY’. The default is to install in ‘/usr/local’. | |
58 | ||
59 | ‘--exec-prefix=DIRECTORY’ | |
60 | Install the library and other machine-dependent files in | |
61 | subdirectories of ‘DIRECTORY’. The default is to the ‘--prefix’ | |
62 | directory if that option is specified, or ‘/usr/local’ otherwise. | |
63 | ||
64 | ‘--with-headers=DIRECTORY’ | |
65 | Look for kernel header files in DIRECTORY, not ‘/usr/include’. The | |
66 | GNU C Library needs information from the kernel’s header files | |
67 | describing the interface to the kernel. The GNU C Library will | |
68 | normally look in ‘/usr/include’ for them, but if you specify this | |
69 | option, it will look in DIRECTORY instead. | |
70 | ||
71 | This option is primarily of use on a system where the headers in | |
72 | ‘/usr/include’ come from an older version of the GNU C Library. | |
73 | Conflicts can occasionally happen in this case. You can also use | |
74 | this option if you want to compile the GNU C Library with a newer | |
75 | set of kernel headers than the ones found in ‘/usr/include’. | |
76 | ||
77 | ‘--enable-kernel=VERSION’ | |
78 | This option is currently only useful on GNU/Linux systems. The | |
79 | VERSION parameter should have the form X.Y.Z and describes the | |
80 | smallest version of the Linux kernel the generated library is | |
81 | expected to support. The higher the VERSION number is, the less | |
82 | compatibility code is added, and the faster the code gets. | |
83 | ||
84 | ‘--with-binutils=DIRECTORY’ | |
85 | Use the binutils (assembler and linker) in ‘DIRECTORY’, not the | |
86 | ones the C compiler would default to. You can use this option if | |
87 | the default binutils on your system cannot deal with all the | |
88 | constructs in the GNU C Library. In that case, ‘configure’ will | |
89 | detect the problem and suppress these constructs, so that the | |
90 | library will still be usable, but functionality may be lost—for | |
91 | example, you can’t build a shared libc with old binutils. | |
92 | ||
93 | ‘--with-nonshared-cflags=CFLAGS’ | |
94 | Use additional compiler flags CFLAGS to build the parts of the | |
95 | library which are always statically linked into applications and | |
96 | libraries even with shared linking (that is, the object files | |
97 | contained in ‘lib*_nonshared.a’ libraries). The build process will | |
98 | automatically use the appropriate flags, but this option can be | |
99 | used to set additional flags required for building applications and | |
100 | libraries, to match local policy. For example, if such a policy | |
101 | requires that all code linked into applications must be built with | |
102 | source fortification, | |
103 | ‘--with-nonshared-cflags=-Wp,-D_FORTIFY_SOURCE=2’ will make sure | |
104 | that the objects in ‘libc_nonshared.a’ are compiled with this flag | |
105 | (although this will not affect the generated code in this | |
106 | particular case and potentially change debugging information and | |
107 | metadata only). | |
108 | ||
109 | ‘--with-rtld-early-cflags=CFLAGS’ | |
110 | Use additional compiler flags CFLAGS to build the early startup | |
111 | code of the dynamic linker. These flags can be used to enable | |
112 | early dynamic linker diagnostics to run on CPUs which are not | |
113 | compatible with the rest of the GNU C Library, for example, due to | |
114 | compiler flags which target a later instruction set architecture | |
115 | (ISA). | |
116 | ||
117 | ‘--with-timeoutfactor=NUM’ | |
118 | Specify an integer NUM to scale the timeout of test programs. This | |
119 | factor can be changed at run time using ‘TIMEOUTFACTOR’ environment | |
120 | variable. | |
121 | ||
122 | ‘--disable-shared’ | |
123 | Don’t build shared libraries even if it is possible. Not all | |
124 | systems support shared libraries; you need ELF support and | |
125 | (currently) the GNU linker. | |
126 | ||
127 | ‘--disable-default-pie’ | |
128 | Don’t build glibc programs and the testsuite as position | |
129 | independent executables (PIE). By default, glibc programs and tests | |
130 | are created as position independent executables on targets that | |
131 | support it. If the toolchain and architecture support it, static | |
132 | executables are built as static PIE and the resulting glibc can be | |
133 | used with the GCC option, -static-pie, which is available with GCC | |
134 | 8 or above, to create static PIE. | |
135 | ||
136 | ‘--enable-cet’ | |
137 | ‘--enable-cet=permissive’ | |
138 | Enable Intel Control-flow Enforcement Technology (CET) support. | |
139 | When the GNU C Library is built with ‘--enable-cet’ or | |
140 | ‘--enable-cet=permissive’, the resulting library is protected with | |
141 | indirect branch tracking (IBT) and shadow stack (SHSTK). When CET | |
142 | is enabled, the GNU C Library is compatible with all existing | |
143 | executables and shared libraries. This feature is currently | |
144 | supported on x86_64 and x32 with GCC 8 and binutils 2.29 or later. | |
145 | With ‘--enable-cet’, it is an error to dlopen a non CET enabled | |
146 | shared library in CET enabled application. With | |
147 | ‘--enable-cet=permissive’, CET is disabled when dlopening a non CET | |
148 | enabled shared library in CET enabled application. | |
149 | ||
150 | NOTE: ‘--enable-cet’ is only supported on x86_64 and x32. | |
151 | ||
152 | ‘--enable-memory-tagging’ | |
153 | Enable memory tagging support if the architecture supports it. | |
154 | When the GNU C Library is built with this option then the resulting | |
155 | library will be able to control the use of tagged memory when | |
156 | hardware support is present by use of the tunable | |
157 | ‘glibc.mem.tagging’. This includes the generation of tagged memory | |
158 | when using the ‘malloc’ APIs. | |
159 | ||
160 | At present only AArch64 platforms with MTE provide this | |
161 | functionality, although the library will still operate (without | |
162 | memory tagging) on older versions of the architecture. | |
163 | ||
164 | The default is to disable support for memory tagging. | |
165 | ||
166 | ‘--disable-profile’ | |
167 | Don’t build libraries with profiling information. You may want to | |
168 | use this option if you don’t plan to do profiling. | |
169 | ||
170 | ‘--enable-static-nss’ | |
171 | Compile static versions of the NSS (Name Service Switch) libraries. | |
172 | This is not recommended because it defeats the purpose of NSS; a | |
173 | program linked statically with the NSS libraries cannot be | |
174 | dynamically reconfigured to use a different name database. | |
175 | ||
176 | ‘--enable-hardcoded-path-in-tests’ | |
177 | By default, dynamic tests are linked to run with the installed C | |
178 | library. This option hardcodes the newly built C library path in | |
179 | dynamic tests so that they can be invoked directly. | |
180 | ||
181 | ‘--disable-timezone-tools’ | |
182 | By default, timezone related utilities (‘zic’, ‘zdump’, and | |
183 | ‘tzselect’) are installed with the GNU C Library. If you are | |
184 | building these independently (e.g. by using the ‘tzcode’ package), | |
185 | then this option will allow disabling the install of these. | |
186 | ||
187 | Note that you need to make sure the external tools are kept in sync | |
188 | with the versions that the GNU C Library expects as the data | |
189 | formats may change over time. Consult the ‘timezone’ subdirectory | |
190 | for more details. | |
191 | ||
192 | ‘--enable-stack-protector’ | |
193 | ‘--enable-stack-protector=strong’ | |
194 | ‘--enable-stack-protector=all’ | |
195 | Compile the C library and all other parts of the glibc package | |
196 | (including the threading and math libraries, NSS modules, and | |
197 | transliteration modules) using the GCC ‘-fstack-protector’, | |
198 | ‘-fstack-protector-strong’ or ‘-fstack-protector-all’ options to | |
199 | detect stack overruns. Only the dynamic linker and a small number | |
200 | of routines called directly from assembler are excluded from this | |
201 | protection. | |
202 | ||
203 | ‘--enable-bind-now’ | |
204 | Disable lazy binding for installed shared objects and programs. | |
205 | This provides additional security hardening because it enables full | |
206 | RELRO and a read-only global offset table (GOT), at the cost of | |
207 | slightly increased program load times. | |
208 | ||
209 | ‘--enable-pt_chown’ | |
210 | The file ‘pt_chown’ is a helper binary for ‘grantpt’ (*note | |
211 | Pseudo-Terminals: Allocation.) that is installed setuid root to fix | |
212 | up pseudo-terminal ownership on GNU/Hurd. It is not required on | |
213 | GNU/Linux, and the GNU C Library will not use the installed | |
214 | ‘pt_chown’ program when configured with ‘--enable-pt_chown’. | |
215 | ||
216 | ‘--disable-werror’ | |
217 | By default, the GNU C Library is built with ‘-Werror’. If you wish | |
218 | to build without this option (for example, if building with a newer | |
219 | version of GCC than this version of the GNU C Library was tested | |
220 | with, so new warnings cause the build with ‘-Werror’ to fail), you | |
221 | can configure with ‘--disable-werror’. | |
222 | ||
223 | ‘--disable-mathvec’ | |
224 | By default for x86_64, the GNU C Library is built with the vector | |
225 | math library. Use this option to disable the vector math library. | |
226 | ||
227 | ‘--disable-scv’ | |
228 | Disable using ‘scv’ instruction for syscalls. All syscalls will | |
229 | use ‘sc’ instead, even if the kernel supports ‘scv’. PowerPC only. | |
230 | ||
231 | ‘--build=BUILD-SYSTEM’ | |
232 | ‘--host=HOST-SYSTEM’ | |
233 | These options are for cross-compiling. If you specify both options | |
234 | and BUILD-SYSTEM is different from HOST-SYSTEM, ‘configure’ will | |
235 | prepare to cross-compile the GNU C Library from BUILD-SYSTEM to be | |
236 | used on HOST-SYSTEM. You’ll probably need the ‘--with-headers’ | |
237 | option too, and you may have to override CONFIGURE’s selection of | |
238 | the compiler and/or binutils. | |
239 | ||
240 | If you only specify ‘--host’, ‘configure’ will prepare for a native | |
241 | compile but use what you specify instead of guessing what your | |
242 | system is. This is most useful to change the CPU submodel. For | |
243 | example, if ‘configure’ guesses your machine as ‘i686-pc-linux-gnu’ | |
244 | but you want to compile a library for 586es, give | |
245 | ‘--host=i586-pc-linux-gnu’ or just ‘--host=i586-linux’ and add the | |
246 | appropriate compiler flags (‘-mcpu=i586’ will do the trick) to | |
247 | ‘CC’. | |
248 | ||
249 | If you specify just ‘--build’, ‘configure’ will get confused. | |
250 | ||
251 | ‘--with-pkgversion=VERSION’ | |
252 | Specify a description, possibly including a build number or build | |
253 | date, of the binaries being built, to be included in ‘--version’ | |
254 | output from programs installed with the GNU C Library. For | |
255 | example, ‘--with-pkgversion='FooBar GNU/Linux glibc build 123'’. | |
256 | The default value is ‘GNU libc’. | |
257 | ||
258 | ‘--with-bugurl=URL’ | |
259 | Specify the URL that users should visit if they wish to report a | |
260 | bug, to be included in ‘--help’ output from programs installed with | |
261 | the GNU C Library. The default value refers to the main | |
262 | bug-reporting information for the GNU C Library. | |
263 | ||
264 | ‘--enable-fortify-source’ | |
265 | ‘--enable-fortify-source=LEVEL’ | |
266 | Use -D_FORTIFY_SOURCE=‘LEVEL’ to control hardening in the GNU C | |
267 | Library. If not provided, ‘LEVEL’ defaults to highest possible | |
268 | value supported by the build compiler. | |
269 | ||
270 | Default is to disable fortification. | |
271 | ||
272 | To build the library and related programs, type ‘make’. This will | |
273 | produce a lot of output, some of which may look like errors from ‘make’ | |
274 | but aren’t. Look for error messages from ‘make’ containing ‘***’. | |
275 | Those indicate that something is seriously wrong. | |
276 | ||
277 | The compilation process can take a long time, depending on the | |
278 | configuration and the speed of your machine. Some complex modules may | |
279 | take a very long time to compile, as much as several minutes on slower | |
280 | machines. Do not panic if the compiler appears to hang. | |
281 | ||
282 | If you want to run a parallel make, simply pass the ‘-j’ option with | |
283 | an appropriate numeric parameter to ‘make’. You need a recent GNU | |
284 | ‘make’ version, though. | |
285 | ||
286 | To build and run test programs which exercise some of the library | |
287 | facilities, type ‘make check’. If it does not complete successfully, do | |
288 | not use the built library, and report a bug after verifying that the | |
289 | problem is not already known. *Note Reporting Bugs::, for instructions | |
290 | on reporting bugs. Note that some of the tests assume they are not | |
291 | being run by ‘root’. We recommend you compile and test the GNU C | |
292 | Library as an unprivileged user. | |
293 | ||
294 | Before reporting bugs make sure there is no problem with your system. | |
295 | The tests (and later installation) use some pre-existing files of the | |
296 | system such as ‘/etc/passwd’, ‘/etc/nsswitch.conf’ and others. These | |
297 | files must all contain correct and sensible content. | |
298 | ||
299 | Normally, ‘make check’ will run all the tests before reporting all | |
300 | problems found and exiting with error status if any problems occurred. | |
301 | You can specify ‘stop-on-test-failure=y’ when running ‘make check’ to | |
302 | make the test run stop and exit with an error status immediately when a | |
303 | failure occurs. | |
304 | ||
305 | To format the ‘GNU C Library Reference Manual’ for printing, type | |
306 | ‘make dvi’. You need a working TeX installation to do this. The | |
307 | distribution builds the on-line formatted version of the manual, as Info | |
308 | files, as part of the build process. You can build them manually with | |
309 | ‘make info’. | |
310 | ||
311 | The library has a number of special-purpose configuration parameters | |
312 | which you can find in ‘Makeconfig’. These can be overwritten with the | |
313 | file ‘configparms’. To change them, create a ‘configparms’ in your | |
314 | build directory and add values as appropriate for your system. The file | |
315 | is included and parsed by ‘make’ and has to follow the conventions for | |
316 | makefiles. | |
317 | ||
318 | It is easy to configure the GNU C Library for cross-compilation by | |
319 | setting a few variables in ‘configparms’. Set ‘CC’ to the | |
320 | cross-compiler for the target you configured the library for; it is | |
321 | important to use this same ‘CC’ value when running ‘configure’, like | |
322 | this: ‘configure TARGET CC=TARGET-gcc’. Set ‘BUILD_CC’ to the compiler | |
323 | to use for programs run on the build system as part of compiling the | |
324 | library. You may need to set ‘AR’ to cross-compiling versions of ‘ar’ | |
325 | if the native tools are not configured to work with object files for the | |
326 | target you configured for. When cross-compiling the GNU C Library, it | |
327 | may be tested using ‘make check | |
328 | test-wrapper="SRCDIR/scripts/cross-test-ssh.sh HOSTNAME"’, where SRCDIR | |
329 | is the absolute directory name for the main source directory and | |
330 | HOSTNAME is the host name of a system that can run the newly built | |
331 | binaries of the GNU C Library. The source and build directories must be | |
332 | visible at the same locations on both the build system and HOSTNAME. | |
333 | The ‘cross-test-ssh.sh’ script requires ‘flock’ from ‘util-linux’ to | |
334 | work when GLIBC_TEST_ALLOW_TIME_SETTING environment variable is set. | |
335 | ||
336 | It is also possible to execute tests, which require setting the date | |
337 | on the target machine. Following use cases are supported: | |
338 | • ‘GLIBC_TEST_ALLOW_TIME_SETTING’ is set in the environment in which | |
339 | eligible tests are executed and have the privilege to run | |
340 | ‘clock_settime’. In this case, nothing prevents those tests from | |
341 | running in parallel, so the caller shall assure that those tests | |
342 | are serialized or provide a proper wrapper script for them. | |
343 | ||
344 | • The ‘cross-test-ssh.sh’ script is used and one passes the | |
345 | ‘--allow-time-setting’ flag. In this case, both sets | |
346 | ‘GLIBC_TEST_ALLOW_TIME_SETTING’ and serialization of test execution | |
347 | are assured automatically. | |
348 | ||
349 | In general, when testing the GNU C Library, ‘test-wrapper’ may be set | |
350 | to the name and arguments of any program to run newly built binaries. | |
351 | This program must preserve the arguments to the binary being run, its | |
352 | working directory and the standard input, output and error file | |
353 | descriptors. If ‘TEST-WRAPPER env’ will not work to run a program with | |
354 | environment variables set, then ‘test-wrapper-env’ must be set to a | |
355 | program that runs a newly built program with environment variable | |
356 | assignments in effect, those assignments being specified as ‘VAR=VALUE’ | |
357 | before the name of the program to be run. If multiple assignments to | |
358 | the same variable are specified, the last assignment specified must take | |
359 | precedence. Similarly, if ‘TEST-WRAPPER env -i’ will not work to run a | |
360 | program with an environment completely empty of variables except those | |
361 | directly assigned, then ‘test-wrapper-env-only’ must be set; its use has | |
362 | the same syntax as ‘test-wrapper-env’, the only difference in its | |
363 | semantics being starting with an empty set of environment variables | |
364 | rather than the ambient set. | |
365 | ||
366 | For AArch64 with SVE, when testing the GNU C Library, ‘test-wrapper’ | |
367 | may be set to "SRCDIR/sysdeps/unix/sysv/linux/aarch64/vltest.py | |
368 | VECTOR-LENGTH" to change Vector Length. | |
369 | ||
370 | Installing the C Library | |
371 | ======================== | |
372 | ||
373 | To install the library and its header files, and the Info files of the | |
374 | manual, type ‘make install’. This will build things, if necessary, | |
375 | before installing them; however, you should still compile everything | |
376 | first. If you are installing the GNU C Library as your primary C | |
377 | library, we recommend that you shut the system down to single-user mode | |
378 | first, and reboot afterward. This minimizes the risk of breaking things | |
379 | when the library changes out from underneath. | |
380 | ||
381 | ‘make install’ will do the entire job of upgrading from a previous | |
382 | installation of the GNU C Library version 2.x. There may sometimes be | |
383 | headers left behind from the previous installation, but those are | |
384 | generally harmless. If you want to avoid leaving headers behind you can | |
385 | do things in the following order. | |
386 | ||
387 | You must first build the library (‘make’), optionally check it (‘make | |
388 | check’), switch the include directories and then install (‘make | |
389 | install’). The steps must be done in this order. Not moving the | |
390 | directory before install will result in an unusable mixture of header | |
391 | files from both libraries, but configuring, building, and checking the | |
392 | library requires the ability to compile and run programs against the old | |
393 | library. The new ‘/usr/include’, after switching the include | |
394 | directories and before installing the library should contain the Linux | |
395 | headers, but nothing else. If you do this, you will need to restore any | |
396 | headers from libraries other than the GNU C Library yourself after | |
397 | installing the library. | |
398 | ||
399 | You can install the GNU C Library somewhere other than where you | |
400 | configured it to go by setting the ‘DESTDIR’ GNU standard make variable | |
401 | on the command line for ‘make install’. The value of this variable is | |
402 | prepended to all the paths for installation. This is useful when | |
403 | setting up a chroot environment or preparing a binary distribution. The | |
404 | directory should be specified with an absolute file name. Installing | |
405 | with the ‘prefix’ and ‘exec_prefix’ GNU standard make variables set is | |
406 | not supported. | |
407 | ||
408 | The GNU C Library includes a daemon called ‘nscd’, which you may or | |
409 | may not want to run. ‘nscd’ caches name service lookups; it can | |
410 | dramatically improve performance with NIS+, and may help with DNS as | |
411 | well. | |
412 | ||
413 | One auxiliary program, ‘/usr/libexec/pt_chown’, is installed setuid | |
414 | ‘root’ if the ‘--enable-pt_chown’ configuration option is used. This | |
415 | program is invoked by the ‘grantpt’ function; it sets the permissions on | |
416 | a pseudoterminal so it can be used by the calling process. If you are | |
417 | using a Linux kernel with the ‘devpts’ filesystem enabled and mounted at | |
418 | ‘/dev/pts’, you don’t need this program. | |
419 | ||
420 | After installation you should configure the timezone and install | |
421 | locales for your system. The time zone configuration ensures that your | |
422 | system time matches the time for your current timezone. The locales | |
423 | ensure that the display of information on your system matches the | |
424 | expectations of your language and geographic region. | |
425 | ||
426 | The GNU C Library is able to use two kinds of localization | |
427 | information sources, the first is a locale database named | |
428 | ‘locale-archive’ which is generally installed as | |
429 | ‘/usr/lib/locale/locale-archive’. The locale archive has the benefit of | |
430 | taking up less space and being very fast to load, but only if you plan | |
431 | to install sixty or more locales. If you plan to install one or two | |
432 | locales you can instead install individual locales into their self-named | |
433 | directories e.g. ‘/usr/lib/locale/en_US.utf8’. For example to install | |
434 | the German locale using the character set for UTF-8 with name ‘de_DE’ | |
435 | into the locale archive issue the command ‘localedef -i de_DE -f UTF-8 | |
436 | de_DE’, and to install just the one locale issue the command ‘localedef | |
437 | --no-archive -i de_DE -f UTF-8 de_DE’. To configure all locales that | |
438 | are supported by the GNU C Library, you can issue from your build | |
439 | directory the command ‘make localedata/install-locales’ to install all | |
440 | locales into the locale archive or ‘make | |
441 | localedata/install-locale-files’ to install all locales as files in the | |
442 | default configured locale installation directory (derived from | |
443 | ‘--prefix’ or ‘--localedir’). To install into an alternative system | |
444 | root use ‘DESTDIR’ e.g. ‘make localedata/install-locale-files | |
445 | DESTDIR=/opt/glibc’, but note that this does not change the configured | |
446 | prefix. | |
447 | ||
448 | To configure the locally used timezone, set the ‘TZ’ environment | |
449 | variable. The script ‘tzselect’ helps you to select the right value. | |
450 | As an example, for Germany, ‘tzselect’ would tell you to use | |
451 | ‘TZ='Europe/Berlin'’. For a system wide installation (the given paths | |
452 | are for an installation with ‘--prefix=/usr’), link the timezone file | |
453 | which is in ‘/usr/share/zoneinfo’ to the file ‘/etc/localtime’. For | |
454 | Germany, you might execute ‘ln -s /usr/share/zoneinfo/Europe/Berlin | |
455 | /etc/localtime’. | |
456 | ||
457 | Recommended Tools for Compilation | |
458 | ================================= | |
459 | ||
460 | We recommend installing the following GNU tools before attempting to | |
461 | build the GNU C Library: | |
462 | ||
463 | • GNU ‘make’ 4.0 or newer | |
464 | ||
465 | As of release time, GNU ‘make’ 4.4 is the newest verified to work | |
466 | to build the GNU C Library. | |
467 | ||
468 | • GCC 6.2 or newer | |
469 | ||
470 | GCC 6.2 or higher is required. In general it is recommended to use | |
471 | the newest version of the compiler that is known to work for | |
472 | building the GNU C Library, as newer compilers usually produce | |
473 | better code. As of release time, GCC 13.2 is the newest compiler | |
474 | verified to work to build the GNU C Library. | |
475 | ||
476 | For PowerPC 64-bits little-endian (powerpc64le), a GCC version with | |
477 | support for ‘-mno-gnu-attribute’, ‘-mabi=ieeelongdouble’, and | |
478 | ‘-mabi=ibmlondouble’ is required. Likewise, the compiler must also | |
479 | support passing ‘-mlong-double-128’ with the preceding options. As | |
480 | of release, this implies GCC 7.4 and newer (excepting GCC 7.5.0, | |
481 | see GCC PR94200). These additional features are required for | |
482 | building the GNU C Library with support for IEEE long double. | |
483 | ||
484 | For ARC architecture builds, GCC 8.3 or higher is needed. | |
485 | ||
486 | For s390x architecture builds, GCC 7.1 or higher is needed (See gcc | |
487 | Bug 98269). | |
488 | ||
489 | For AArch64 architecture builds with mathvec enabled, GCC 10 or | |
490 | higher is needed due to dependency on arm_sve.h. | |
491 | ||
492 | For multi-arch support it is recommended to use a GCC which has | |
493 | been built with support for GNU indirect functions. This ensures | |
494 | that correct debugging information is generated for functions | |
495 | selected by IFUNC resolvers. This support can either be enabled by | |
496 | configuring GCC with ‘--enable-gnu-indirect-function’, or by | |
497 | enabling it by default by setting ‘default_gnu_indirect_function’ | |
498 | variable for a particular architecture in the GCC source file | |
499 | ‘gcc/config.gcc’. | |
500 | ||
501 | You can use whatever compiler you like to compile programs that use | |
502 | the GNU C Library. | |
503 | ||
504 | Check the FAQ for any special compiler issues on particular | |
505 | platforms. | |
506 | ||
507 | • GNU ‘binutils’ 2.25 or later | |
508 | ||
509 | You must use GNU ‘binutils’ (as and ld) to build the GNU C Library. | |
510 | No other assembler or linker has the necessary functionality at the | |
511 | moment. As of release time, GNU ‘binutils’ 2.41 is the newest | |
512 | verified to work to build the GNU C Library. | |
513 | ||
514 | For PowerPC 64-bits little-endian (powerpc64le), ‘objcopy’ is | |
515 | required to support ‘--update-section’. This option requires | |
516 | binutils 2.26 or newer. | |
517 | ||
518 | ARC architecture needs ‘binutils’ 2.32 or higher for TLS related | |
519 | fixes. | |
520 | ||
521 | • GNU ‘texinfo’ 4.7 or later | |
522 | ||
523 | To correctly translate and install the Texinfo documentation you | |
524 | need this version of the ‘texinfo’ package. Earlier versions do | |
525 | not understand all the tags used in the document, and the | |
526 | installation mechanism for the info files is not present or works | |
527 | differently. As of release time, ‘texinfo’ 7.0.3 is the newest | |
528 | verified to work to build the GNU C Library. | |
529 | ||
530 | • GNU ‘awk’ 3.1.2, or higher | |
531 | ||
532 | ‘awk’ is used in several places to generate files. Some ‘gawk’ | |
533 | extensions are used, including the ‘asorti’ function, which was | |
534 | introduced in version 3.1.2 of ‘gawk’. As of release time, ‘gawk’ | |
535 | version 5.2.2 is the newest verified to work to build the GNU C | |
536 | Library. | |
537 | ||
538 | • GNU ‘bison’ 2.7 or later | |
539 | ||
540 | ‘bison’ is used to generate the ‘yacc’ parser code in the ‘intl’ | |
541 | subdirectory. As of release time, ‘bison’ version 3.8.2 is the | |
542 | newest verified to work to build the GNU C Library. | |
543 | ||
544 | • Perl 5 | |
545 | ||
546 | Perl is not required, but if present it is used in some tests and | |
547 | the ‘mtrace’ program, to build the GNU C Library manual. As of | |
548 | release time ‘perl’ version 5.38.0 is the newest verified to work | |
549 | to build the GNU C Library. | |
550 | ||
551 | • GNU ‘sed’ 3.02 or newer | |
552 | ||
553 | ‘Sed’ is used in several places to generate files. Most scripts | |
554 | work with any version of ‘sed’. As of release time, ‘sed’ version | |
555 | 4.9 is the newest verified to work to build the GNU C Library. | |
556 | ||
557 | • Python 3.4 or later | |
558 | ||
559 | Python is required to build the GNU C Library. As of release time, | |
560 | Python 3.11 is the newest verified to work for building and testing | |
561 | the GNU C Library. | |
562 | ||
563 | • PExpect 4.0 | |
564 | ||
565 | The pretty printer tests drive GDB through test programs and | |
566 | compare its output to the printers’. PExpect is used to capture | |
567 | the output of GDB, and should be compatible with the Python version | |
568 | in your system. As of release time PExpect 4.8.0 is the newest | |
569 | verified to work to test the pretty printers. | |
570 | ||
571 | • The Python ‘abnf’ module. | |
572 | ||
573 | This module is optional and used to verify some ABNF grammars in | |
574 | the manual. Version 2.2.0 has been confirmed to work as expected. | |
575 | A missing ‘abnf’ module does not reduce the test coverage of the | |
576 | library itself. | |
577 | ||
578 | • GDB 7.8 or later with support for Python 2.7/3.4 or later | |
579 | ||
580 | GDB itself needs to be configured with Python support in order to | |
581 | use the pretty printers. Notice that your system having Python | |
582 | available doesn’t imply that GDB supports it, nor that your | |
583 | system’s Python and GDB’s have the same version. As of release | |
584 | time GNU ‘debugger’ 13.2 is the newest verified to work to test the | |
585 | pretty printers. | |
586 | ||
587 | Unless Python, PExpect and GDB with Python support are present, the | |
588 | printer tests will report themselves as ‘UNSUPPORTED’. Notice that | |
589 | some of the printer tests require the GNU C Library to be compiled | |
590 | with debugging symbols. | |
591 | ||
592 | If you change any of the ‘configure.ac’ files you will also need | |
593 | ||
594 | • GNU ‘autoconf’ 2.71 (exactly) | |
595 | ||
596 | and if you change any of the message translation files you will need | |
597 | ||
598 | • GNU ‘gettext’ 0.10.36 or later | |
599 | ||
600 | As of release time, GNU ‘gettext’ version 0.21.1 is the newest | |
601 | version verified to work to build the GNU C Library. | |
602 | ||
603 | You may also need these packages if you upgrade your source tree using | |
604 | patches, although we try to avoid this. | |
605 | ||
606 | Specific advice for GNU/Linux systems | |
607 | ===================================== | |
608 | ||
609 | If you are installing the GNU C Library on GNU/Linux systems, you need | |
610 | to have the header files from a 3.2 or newer kernel around for | |
611 | reference. These headers must be installed using ‘make | |
612 | headers_install’; the headers present in the kernel source directory are | |
613 | not suitable for direct use by the GNU C Library. You do not need to | |
614 | use that kernel, just have its headers installed where the GNU C Library | |
615 | can access them, referred to here as INSTALL-DIRECTORY. The easiest way | |
616 | to do this is to unpack it in a directory such as | |
617 | ‘/usr/src/linux-VERSION’. In that directory, run ‘make headers_install | |
618 | INSTALL_HDR_PATH=INSTALL-DIRECTORY’. Finally, configure the GNU C | |
619 | Library with the option ‘--with-headers=INSTALL-DIRECTORY/include’. Use | |
620 | the most recent kernel you can get your hands on. (If you are | |
621 | cross-compiling the GNU C Library, you need to specify | |
622 | ‘ARCH=ARCHITECTURE’ in the ‘make headers_install’ command, where | |
623 | ARCHITECTURE is the architecture name used by the Linux kernel, such as | |
624 | ‘x86’ or ‘powerpc’.) | |
625 | ||
626 | After installing the GNU C Library, you may need to remove or rename | |
627 | directories such as ‘/usr/include/linux’ and ‘/usr/include/asm’, and | |
628 | replace them with copies of directories such as ‘linux’ and ‘asm’ from | |
629 | ‘INSTALL-DIRECTORY/include’. All directories present in | |
630 | ‘INSTALL-DIRECTORY/include’ should be copied, except that the GNU C | |
631 | Library provides its own version of ‘/usr/include/scsi’; the files | |
632 | provided by the kernel should be copied without replacing those provided | |
633 | by the GNU C Library. The ‘linux’, ‘asm’ and ‘asm-generic’ directories | |
634 | are required to compile programs using the GNU C Library; the other | |
635 | directories describe interfaces to the kernel but are not required if | |
636 | not compiling programs using those interfaces. You do not need to copy | |
637 | kernel headers if you did not specify an alternate kernel header source | |
638 | using ‘--with-headers’. | |
639 | ||
640 | The Filesystem Hierarchy Standard for GNU/Linux systems expects some | |
641 | components of the GNU C Library installation to be in ‘/lib’ and some in | |
642 | ‘/usr/lib’. This is handled automatically if you configure the GNU C | |
643 | Library with ‘--prefix=/usr’. If you set some other prefix or allow it | |
644 | to default to ‘/usr/local’, then all the components are installed there. | |
645 | ||
646 | As of release time, Linux version 6.1.5 is the newest stable version | |
647 | verified to work to build the GNU C Library. | |
648 | ||
649 | Reporting Bugs | |
650 | ============== | |
651 | ||
652 | There are probably bugs in the GNU C Library. There are certainly | |
653 | errors and omissions in this manual. If you report them, they will get | |
654 | fixed. If you don’t, no one will ever know about them and they will | |
655 | remain unfixed for all eternity, if not longer. | |
656 | ||
657 | It is a good idea to verify that the problem has not already been | |
658 | reported. Bugs are documented in two places: The file ‘BUGS’ describes | |
659 | a number of well known bugs and the central GNU C Library bug tracking | |
660 | system has a WWW interface at <https://sourceware.org/bugzilla/>. The | |
661 | WWW interface gives you access to open and closed reports. A closed | |
662 | report normally includes a patch or a hint on solving the problem. | |
663 | ||
664 | To report a bug, first you must find it. With any luck, this will be | |
665 | the hard part. Once you’ve found a bug, make sure it’s really a bug. A | |
666 | good way to do this is to see if the GNU C Library behaves the same way | |
667 | some other C library does. If so, probably you are wrong and the | |
668 | libraries are right (but not necessarily). If not, one of the libraries | |
669 | is probably wrong. It might not be the GNU C Library. Many historical | |
670 | Unix C libraries permit things that we don’t, such as closing a file | |
671 | twice. | |
672 | ||
673 | If you think you have found some way in which the GNU C Library does | |
674 | not conform to the ISO and POSIX standards (*note Standards and | |
675 | Portability::), that is definitely a bug. Report it! | |
676 | ||
677 | Once you’re sure you’ve found a bug, try to narrow it down to the | |
678 | smallest test case that reproduces the problem. In the case of a C | |
679 | library, you really only need to narrow it down to one library function | |
680 | call, if possible. This should not be too difficult. | |
681 | ||
682 | The final step when you have a simple test case is to report the bug. | |
683 | Do this at <https://www.gnu.org/software/libc/bugs.html>. | |
684 | ||
685 | If you are not sure how a function should behave, and this manual | |
686 | doesn’t tell you, that’s a bug in the manual. Report that too! If the | |
687 | function’s behavior disagrees with the manual, then either the library | |
688 | or the manual has a bug, so report the disagreement. If you find any | |
689 | errors or omissions in this manual, please report them to the bug | |
690 | database. If you refer to specific sections of the manual, please | |
691 | include the section names for easier identification. |