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