| <html lang="en"> |
| <head> |
| <title>Configuring and compiling - The GNU C Library</title> |
| <meta http-equiv="Content-Type" content="text/html"> |
| <meta name="description" content="The GNU C Library"> |
| <meta name="generator" content="makeinfo 4.13"> |
| <link title="Top" rel="start" href="index.html#Top"> |
| <link rel="up" href="Installation.html#Installation" title="Installation"> |
| <link rel="next" href="Running-make-install.html#Running-make-install" title="Running make install"> |
| <link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> |
| <!-- |
| This file documents the GNU C library. |
| |
| This is Edition 0.12, last updated 2007-10-27, |
| of `The GNU C Library Reference Manual', for version |
| 2.8 (Sourcery G++ Lite 2011.03-41). |
| |
| Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002, |
| 2003, 2007, 2008, 2010 Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.3 or |
| any later version published by the Free Software Foundation; with the |
| Invariant Sections being ``Free Software Needs Free Documentation'' |
| and ``GNU Lesser General Public License'', the Front-Cover texts being |
| ``A GNU Manual'', and with the Back-Cover Texts as in (a) below. A |
| copy of the license is included in the section entitled "GNU Free |
| Documentation License". |
| |
| (a) The FSF's Back-Cover Text is: ``You have the freedom to |
| copy and modify this GNU manual. Buying copies from the FSF |
| supports it in developing GNU and promoting software freedom.''--> |
| <meta http-equiv="Content-Style-Type" content="text/css"> |
| <style type="text/css"><!-- |
| pre.display { font-family:inherit } |
| pre.format { font-family:inherit } |
| pre.smalldisplay { font-family:inherit; font-size:smaller } |
| pre.smallformat { font-family:inherit; font-size:smaller } |
| pre.smallexample { font-size:smaller } |
| pre.smalllisp { font-size:smaller } |
| span.sc { font-variant:small-caps } |
| span.roman { font-family:serif; font-weight:normal; } |
| span.sansserif { font-family:sans-serif; font-weight:normal; } |
| --></style> |
| <link rel="stylesheet" type="text/css" href="../cs.css"> |
| </head> |
| <body> |
| <div class="node"> |
| <a name="Configuring-and-compiling"></a> |
| <p> |
| Next: <a rel="next" accesskey="n" href="Running-make-install.html#Running-make-install">Running make install</a>, |
| Up: <a rel="up" accesskey="u" href="Installation.html#Installation">Installation</a> |
| <hr> |
| </div> |
| |
| <h3 class="appendixsec">C.1 Configuring and compiling GNU Libc</h3> |
| |
| <p><a name="index-configuring-3813"></a><a name="index-compiling-3814"></a> |
| GNU libc cannot be compiled in the source directory. You must build |
| it in a separate build directory. For example, if you have unpacked |
| the glibc sources in <samp><span class="file">/src/gnu/glibc-2.4</span></samp>, create a directory |
| <samp><span class="file">/src/gnu/glibc-build</span></samp> to put the object files in. This allows |
| removing the whole build directory in case an error occurs, which is |
| the safest way to get a fresh start and should always be done. |
| |
| <p>From your object directory, run the shell script <samp><span class="file">configure</span></samp> located |
| at the top level of the source tree. In the scenario above, you'd type |
| |
| <pre class="smallexample"> $ ../glibc-2.4/configure <var>args<small class="dots">...</small></var> |
| </pre> |
| <p>Please note that even though you're building in a separate build |
| directory, the compilation needs to modify a few files in the source |
| directory, especially some files in the manual subdirectory. |
| |
| <p class="noindent"><code>configure</code> takes many options, but the only one that is usually |
| mandatory is ‘<samp><span class="samp">--prefix</span></samp>’. This option tells <code>configure</code> |
| where you want glibc installed. This defaults to <samp><span class="file">/usr/local</span></samp>, |
| but the normal setting to install as the standard system library is |
| ‘<samp><span class="samp">--prefix=/usr</span></samp>’ for GNU/Linux systems and ‘<samp><span class="samp">--prefix=</span></samp>’ (an |
| empty prefix) for GNU/Hurd systems. |
| |
| <p>It may also be useful to set the <var>CC</var> and <var>CFLAGS</var> variables in |
| the environment when running <code>configure</code>. <var>CC</var> selects the C |
| compiler that will be used, and <var>CFLAGS</var> sets optimization options |
| for the compiler. |
| |
| <p>The following list describes all of the available options for |
| <code>configure</code>: |
| |
| <dl> |
| <dt>‘<samp><span class="samp">--prefix=</span><var>directory</var></samp>’<dd>Install machine-independent data files in subdirectories of |
| <samp><var>directory</var></samp>. The default is to install in <samp><span class="file">/usr/local</span></samp>. |
| |
| <br><dt>‘<samp><span class="samp">--exec-prefix=</span><var>directory</var></samp>’<dd>Install the library and other machine-dependent files in subdirectories |
| of <samp><var>directory</var></samp>. The default is to the ‘<samp><span class="samp">--prefix</span></samp>’ |
| directory if that option is specified, or <samp><span class="file">/usr/local</span></samp> otherwise. |
| |
| <br><dt>‘<samp><span class="samp">--with-headers=</span><var>directory</var></samp>’<dd>Look for kernel header files in <var>directory</var>, not |
| <samp><span class="file">/usr/include</span></samp>. Glibc needs information from the kernel's private |
| header files. Glibc will normally look in <samp><span class="file">/usr/include</span></samp> for them, |
| but if you specify this option, it will look in <var>DIRECTORY</var> instead. |
| |
| <p>This option is primarily of use on a system where the headers in |
| <samp><span class="file">/usr/include</span></samp> come from an older version of glibc. Conflicts can |
| occasionally happen in this case. Note that Linux libc5 qualifies as an |
| older version of glibc. You can also use this option if you want to |
| compile glibc with a newer set of kernel headers than the ones found in |
| <samp><span class="file">/usr/include</span></samp>. |
| |
| <br><dt>‘<samp><span class="samp">--enable-add-ons[=</span><var>list</var><span class="samp">]</span></samp>’<dd>Specify add-on packages to include in the build. If this option is |
| specified with no list, it enables all the add-on packages it finds in |
| the main source directory; this is the default behavior. You may |
| specify an explicit list of add-ons to use in <var>list</var>, separated by |
| spaces or commas (if you use spaces, remember to quote them from the |
| shell). Each add-on in <var>list</var> can be an absolute directory name |
| or can be a directory name relative to the main source directory, or |
| relative to the build directory (that is, the current working directory). |
| For example, ‘<samp><span class="samp">--enable-add-ons=nptl,../glibc-libidn-2.4</span></samp>’. |
| |
| <br><dt>‘<samp><span class="samp">--enable-kernel=</span><var>version</var></samp>’<dd>This option is currently only useful on GNU/Linux systems. The |
| <var>version</var> parameter should have the form X.Y.Z and describes the |
| smallest version of the Linux kernel the generated library is expected |
| to support. The higher the <var>version</var> number is, the less |
| compatibility code is added, and the faster the code gets. |
| |
| <br><dt>‘<samp><span class="samp">--with-binutils=</span><var>directory</var></samp>’<dd>Use the binutils (assembler and linker) in <samp><var>directory</var></samp>, not |
| the ones the C compiler would default to. You can use this option if |
| the default binutils on your system cannot deal with all the constructs |
| in the GNU C library. In that case, <code>configure</code> will detect the |
| problem and suppress these constructs, so that the library will still be |
| usable, but functionality may be lost—for example, you can't build a |
| shared libc with old binutils. |
| |
| <br><dt>‘<samp><span class="samp">--without-fp</span></samp>’<dd>Use this option if your computer lacks hardware floating-point support |
| and your operating system does not emulate an FPU. |
| |
| <!-- disable static doesn't work currently --> |
| <!-- @item -disable-static --> |
| <!-- Don't build static libraries. Static libraries aren't that useful --> |
| <p>these |
| <!-- days, but we recommend you build them in case you need them. --> |
| |
| <br><dt>‘<samp><span class="samp">--disable-shared</span></samp>’<dd>Don't build shared libraries even if it is possible. Not all systems |
| support shared libraries; you need ELF support and (currently) the GNU |
| linker. |
| |
| <br><dt>‘<samp><span class="samp">--disable-profile</span></samp>’<dd>Don't build libraries with profiling information. You may want to use |
| this option if you don't plan to do profiling. |
| |
| <br><dt>‘<samp><span class="samp">--enable-omitfp</span></samp>’<dd>Use maximum optimization for the normal (static and shared) |
| libraries, and compile separate static libraries with debugging |
| information and no optimization. We recommend not doing this. The extra |
| optimization doesn't gain you much, it may provoke compiler bugs, and you |
| won't be able to trace bugs through the C library. |
| |
| <br><dt>‘<samp><span class="samp">--disable-versioning</span></samp>’<dd>Don't compile the shared libraries with symbol version information. |
| Doing this will make the resulting library incompatible with old |
| binaries, so it's not recommended. |
| |
| <br><dt>‘<samp><span class="samp">--enable-static-nss</span></samp>’<dd>Compile static versions of the NSS (Name Service Switch) libraries. |
| This is not recommended because it defeats the purpose of NSS; a program |
| linked statically with the NSS libraries cannot be dynamically |
| reconfigured to use a different name database. |
| |
| <br><dt>‘<samp><span class="samp">--without-tls</span></samp>’<dd>By default the C library is built with support for thread-local storage |
| if the used tools support it. By using ‘<samp><span class="samp">--without-tls</span></samp>’ this can be |
| prevented though there generally is no reason since it creates |
| compatibility problems. |
| |
| <br><dt>‘<samp><span class="samp">--build=</span><var>build-system</var></samp>’<dt>‘<samp><span class="samp">--host=</span><var>host-system</var></samp>’<dd>These options are for cross-compiling. If you specify both options and |
| <var>build-system</var> is different from <var>host-system</var>, <code>configure</code> |
| will prepare to cross-compile glibc from <var>build-system</var> to be used |
| on <var>host-system</var>. You'll probably need the ‘<samp><span class="samp">--with-headers</span></samp>’ |
| option too, and you may have to override <var>configure</var>'s selection of |
| the compiler and/or binutils. |
| |
| <p>If you only specify ‘<samp><span class="samp">--host</span></samp>’, <code>configure</code> will prepare for a |
| native compile but use what you specify instead of guessing what your |
| system is. This is most useful to change the CPU submodel. For example, |
| if <code>configure</code> guesses your machine as <code>i586-pc-linux-gnu</code> but |
| you want to compile a library for 386es, give |
| ‘<samp><span class="samp">--host=i386-pc-linux-gnu</span></samp>’ or just ‘<samp><span class="samp">--host=i386-linux</span></samp>’ and add |
| the appropriate compiler flags (‘<samp><span class="samp">-mcpu=i386</span></samp>’ will do the trick) to |
| <var>CFLAGS</var>. |
| |
| <p>If you specify just ‘<samp><span class="samp">--build</span></samp>’, <code>configure</code> will get confused. |
| </dl> |
| |
| <p>To build the library and related programs, type <code>make</code>. This will |
| produce a lot of output, some of which may look like errors from |
| <code>make</code> but isn't. Look for error messages from <code>make</code> |
| containing ‘<samp><span class="samp">***</span></samp>’. Those indicate that something is seriously wrong. |
| |
| <p>The compilation process can take a long time, depending on the |
| configuration and the speed of your machine. Some complex modules may |
| take a very long time to compile, as much as several minutes on slower |
| machines. Do not panic if the compiler appears to hang. |
| |
| <p>If you want to run a parallel make, simply pass the ‘<samp><span class="samp">-j</span></samp>’ option |
| with an appropriate numeric parameter to <code>make</code>. You need a recent |
| GNU <code>make</code> version, though. |
| |
| <p>To build and run test programs which exercise some of the library |
| facilities, type <code>make check</code>. If it does not complete |
| successfully, do not use the built library, and report a bug after |
| verifying that the problem is not already known. See <a href="Reporting-Bugs.html#Reporting-Bugs">Reporting Bugs</a>, |
| for instructions on reporting bugs. Note that some of the tests assume |
| they are not being run by <code>root</code>. We recommend you compile and |
| test glibc as an unprivileged user. |
| |
| <p>Before reporting bugs make sure there is no problem with your system. |
| The tests (and later installation) use some pre-existing files of the |
| system such as <samp><span class="file">/etc/passwd</span></samp>, <samp><span class="file">/etc/nsswitch.conf</span></samp> and others. |
| These files must all contain correct and sensible content. |
| |
| <p>To format the <cite>GNU C Library Reference Manual</cite> for printing, type |
| <code>make dvi</code><!-- /@w -->. You need a working TeX installation to do this. |
| The distribution already includes the on-line formatted version of the |
| manual, as Info files. You can regenerate those with <code>make info</code><!-- /@w -->, but it shouldn't be necessary. |
| |
| <p>The library has a number of special-purpose configuration parameters |
| which you can find in <samp><span class="file">Makeconfig</span></samp>. These can be overwritten with |
| the file <samp><span class="file">configparms</span></samp>. To change them, create a |
| <samp><span class="file">configparms</span></samp> in your build directory and add values as appropriate |
| for your system. The file is included and parsed by <code>make</code> and has |
| to follow the conventions for makefiles. |
| |
| <p>It is easy to configure the GNU C library for cross-compilation by |
| setting a few variables in <samp><span class="file">configparms</span></samp>. Set <code>CC</code> to the |
| cross-compiler for the target you configured the library for; it is |
| important to use this same <code>CC</code> value when running |
| <code>configure</code>, like this: ‘<samp><span class="samp">CC=</span><var>target</var><span class="samp">-gcc configure |
| </span><var>target</var></samp>’. Set <code>BUILD_CC</code> to the compiler to use for programs |
| run on the build system as part of compiling the library. You may need to |
| set <code>AR</code> and <code>RANLIB</code> to cross-compiling versions of <code>ar</code> |
| and <code>ranlib</code> if the native tools are not configured to work with |
| object files for the target you configured for. |
| |
| </body></html> |
| |
