library_30.html

Linux程序员的工作手册

<!-- This HTML file has been created by texi2html 1.27
     from library.texinfo on 3 March 1994 -->

<TITLE>The GNU C Library - Library Maintenance</TITLE>
<P>Go to the <A HREF="library_29.html" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_29.html">previous</A>, <A HREF="library_31.html" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_31.html">next</A> section.<P>
<H1><A NAME="SEC493" HREF="library_toc.html#SEC493" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC493">Library Maintenance</A></H1>
<P>
<A NAME="IDX1978"></A>
<H2><A NAME="SEC494" HREF="library_toc.html#SEC494" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC494">How to Install the GNU C Library</A></H2>
<P>
Installation of the GNU C library is relatively simple.
<P>
You need the latest version of GNU <CODE>make</CODE>.  Modifying the GNU C
Library to work with other <CODE>make</CODE> programs would be so hard that we
recommend you port GNU <CODE>make</CODE> instead.  <STRONG>Really.</STRONG><P>
To configure the GNU C library for your system, run the shell script
<TT>`configure'</TT> with <CODE>sh</CODE>.  Use an argument which is the
conventional GNU name for your system configuration--for example,
<SAMP>`sparc-sun-sunos4.1'</SAMP>, for a Sun 4 running Sunos 4.1.
See section 'Installing GNU CC' in <CITE>Using and Porting GNU CC</CITE>, for a full description of standard GNU configuration
names.
<P>
The GNU C Library currently supports configurations that match the
following patterns:
<P>
<PRE>
sparc-sun-sunos4.<VAR>n</VAR>
m68k-hp-bsd4.3
m68k-sun-sunos4.<VAR>n</VAR>
m68k-sony-bsd4.3
mips-dec-ultrix4.<VAR>n</VAR>
i386-bsd4.3
i386-sysv
i386-sysv4
</PRE>
<P>
While no other configurations are supported, there are handy aliases for
these few.  (These aliases work in other GNU software as well.)
<P>
<PRE>
sun4-sunos4.<VAR>n</VAR>
hp320-bsd4.3
sun3-sunos4.<VAR>n</VAR>
news
decstation-ultrix
i386-svr4
</PRE>
<P>
Here are some options that you should specify (if appropriate) when
you run <CODE>configure</CODE>:
<P>
<DL COMPACT>
<DT><SAMP>`--with-gnu-ld'</SAMP>
<DD>Use this option if you plan to use GNU <CODE>ld</CODE> to link programs with
the GNU C Library.  (We strongly recommend that you do.)
<P>
<DT><SAMP>`--with-gnu-as'</SAMP>
<DD>Use this option if you plan to use the GNU assembler, <CODE>gas</CODE>, when
building the GNU C Library.  On some systems, the library may not build
properly if you do <EM>not</EM> use <CODE>gas</CODE>.
<P>
<DT><SAMP>`--nfp'</SAMP>
<DD><P>
Use this option if your computer lacks hardware floating point support.
<P>
<DT><SAMP>`--prefix=<VAR>directory</VAR>'</SAMP>
<DD>Install machine-independent data files in subdirectories of
<TT>`<VAR>directory</VAR>'</TT>.  (You can also set this in <TT>`configparms'</TT>;
see below.)
<P>
<DT><SAMP>`--exec-prefix=<VAR>directory</VAR>'</SAMP>
<DD>Install the library and other machine-dependent files in subdirectories
of <TT>`<VAR>directory</VAR>'</TT>.  (You can also set this in
<TT>`configparms'</TT>; see below.)
</DL>
<P>
The simplest way to run <CODE>configure</CODE> is to do it in the directory
that contains the library sources.  This prepares to build the library
in that very directory.
<P>
You can prepare to build the library in some other directory by going
to that other directory to run <CODE>configure</CODE>.  In order to run
configure, you will have to specify a directory for it, like this:
<P>
<PRE>
mkdir ../hp320
cd ../hp320
../src/configure hp320-bsd4.3
</PRE>
<P>
<CODE>configure</CODE> looks for the sources in whatever directory you
specified for finding <CODE>configure</CODE> itself.  It does not matter where
in the file system the source and build directories are--as long as you
specify the source directory when you run <CODE>configure</CODE>, you will get
the proper results.
<P>
This feature lets you keep sources and binaries in different
directories, and that makes it easy to build the library for several
different machines from the same set of sources.  Simply create a 
build directory for each target machine, and run <CODE>configure</CODE> in
that directory specifying the target machine's configuration name.
<P>
The library has a number of special-purpose configuration parameters.
These are defined in the file <TT>`Makeconfig'</TT>; see the comments in
that file for the details.
<P>
But don't edit the file <TT>`Makeconfig'</TT> yourself--instead, create a
file <TT>`configparms'</TT> in the directory where you are building the
library, and define in that file the parameters you want to specify.
<TT>`configparms'</TT> should <STRONG>not</STRONG> be an edited copy of
<TT>`Makeconfig'</TT>; specify only the parameters that you want to
override.
<P>
Some of the machine-dependent code for some machines uses extensions in
the GNU C compiler, so you may need to compile the library with GCC.
(In fact, all of the existing complete ports require GCC.)
<P>
The current release of the C library contains some header files that the
compiler normally provides: <TT>`stddef.h'</TT>, <TT>`stdarg.h'</TT>, and
several files with names of the form <TT>`va-<VAR>machine</VAR>.h'</TT>.  The
versions of these files that came with older releases of GCC do not work
properly with the GNU C library.  The <TT>`stddef.h'</TT> file in release
2.2 and later of GCC is correct.  If you have release 2.2 or later of
GCC, use its version of <TT>`stddef.h'</TT> instead of the C library's.  To
do this, put the line <SAMP>`override stddef.h ='</SAMP> in
<TT>`configparms'</TT>.  The other files are corrected in release 2.3 and
later of GCC.  <TT>`configure'</TT> will automatically detect whether the
installed <TT>`stdarg.h'</TT> and <TT>`va-<VAR>machine</VAR>.h'</TT> files are
compatible with the C library, and use its own if not.
<P>
There is a potential problem with the <CODE>size_t</CODE> type and versions of
GCC prior to release 2.4.  ANSI C requires that <CODE>size_t</CODE> always be
an unsigned type.  For compatibility with existing systems' header
files, GCC defines <CODE>size_t</CODE> in <TT>`stddef.h'</TT> to be whatever type
the system's <TT>`sys/types.h'</TT> defines it to be.  Most Unix systems
that define <CODE>size_t</CODE> in <TT>`sys/types.h'</TT>, define it to be a
signed type.  Some code in the library depends on <CODE>size_t</CODE> being an
unsigned type, and will not work correctly if it is signed.
<P>
The GNU C library code which expects <CODE>size_t</CODE> to be unsigned is
correct.  The definition of <CODE>size_t</CODE> as a signed type is incorrect.
We plan that in version 2.4, GCC will always define <CODE>size_t</CODE> as an
unsigned type, and the <TT>`fixincludes'</TT> script will massage the
system's <TT>`sys/types.h'</TT> so as not to conflict with this.
<P>
In the meantime, we work around this problem by telling GCC explicitly
to use an unsigned type for <CODE>size_t</CODE> when compiling the GNU C
library.  <TT>`configure'</TT> will automatically detect what type GCC uses
for <CODE>size_t</CODE> arrange to override it if necessary.
<P>
To build the library, type <CODE>make lib</CODE>.  This will produce a lot of
output, some of which looks like errors from <CODE>make</CODE> (but isn't).
Look for error messages from <CODE>make</CODE> containing <SAMP>`***'</SAMP>.  Those
indicate that something is really wrong.  Using the <SAMP>`-w'</SAMP> option to
<CODE>make</CODE> may make the output easier to understand (this option tells
<CODE>make</CODE> to print messages telling you what subdirectories it is
working on).<P>
To install the library and header files, type <CODE>make install</CODE>, after
setting the installation directories in <TT>`configparms'</TT>.  This will
build things if necessary, before installing them.<P>
<A NAME="IDX1979"></A>
<H2><A NAME="SEC495" HREF="library_toc.html#SEC495" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC495">Reporting Bugs</A></H2>
<P>
There are probably bugs in the GNU C library.  If you report them,
they will get fixed.  If you don't, no one will ever know about them
and they will remain unfixed for all eternity, if not longer.
<P>
To report a bug, first you must find it.  Hopefully, this will be the
hard part.  Once you've found a bug, make sure it's really a bug.  A
good way to do this is to see if the GNU C library behaves the same way
some other C library does.  If so, probably you are wrong and the
libraries are right (but not necessarily).  If not, one of the libraries
is probably wrong.
<P>
Once you're sure you've found a bug, try to narrow it down to the
smallest test case that reproduces the problem.  In the case of a C
library, you really only need to narrow it down to one library
function call, if possible.  This should not be too difficult.
<P>
The final step when you have a simple test case is to report the
bug.  When reporting a bug, send your test case, the results you
got, the results you expected, what you think the problem might be
(if you've thought of anything), your system type, and the version
of the GNU C library which you are using.
<P>
If you think you have found some way in which the GNU C library does not
conform to the ANSI and POSIX standards (see section <A HREF="library_1.html#SEC3" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_1.html#SEC3">Standards and Portability</A>), that is definitely a bug.  Report it!<P>
Send bug reports to the Internet address
<SAMP>`[e-mail]'</SAMP> or the UUCP path
<SAMP>`mit-eddie!prep.ai.mit.edu!bug-glibc'</SAMP>.  If you have other problems
with installation, use, or the documentation, please report those as
well.<P>
<H2><A NAME="SEC496" HREF="library_toc.html#SEC496" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC496">Adding New Functions</A></H2>
<P>
The process of building the library is driven by the makefiles, which
make heavy use of special features of GNU <CODE>make</CODE>.  The makefiles
are very complex, and you probably don't want to try to understand them.
But what they do is fairly straightforward, and only requires that you
define a few variables in the right places.
<P>
The library sources are divided into subdirectories, grouped by topic.
The <TT>`string'</TT> subdirectory has all the string-manipulation
functions, <TT>`stdio'</TT> has all the standard I/O functions, etc.
<P>
Each subdirectory contains a simple makefile, called <TT>`Makefile'</TT>,
which defines a few <CODE>make</CODE> variables and then includes the global
makefile <TT>`Rules'</TT> with a line like:
<P>
<PRE>
include ../Rules
</PRE>
<P>
The basic variables that a subdirectory makefile defines are:
<P>
<DL COMPACT>
<DT><CODE>subdir</CODE>
<DD>The name of the subdirectory, for example <TT>`stdio'</TT>.
This variable <STRONG>must</STRONG> be defined.
<P>
<DT><CODE>headers</CODE>
<DD>The names of the header files in this section of the library,
such as <TT>`stdio.h'</TT>.
<P>
<DT><CODE>routines</CODE>
<DD><DT><CODE>aux</CODE>
<DD>The names of the modules (source files) in this section of the library.
These should be simple names, such as <SAMP>`strlen'</SAMP> (rather than
complete file names, such as <TT>`strlen.c'</TT>).  Use <CODE>routines</CODE> for