diff options
Diffstat (limited to 'manual/install.texi')
| -rw-r--r-- | manual/install.texi | 24 |
1 files changed, 22 insertions, 2 deletions
diff --git a/manual/install.texi b/manual/install.texi index 4802e699fe..e36fb052ab 100644 --- a/manual/install.texi +++ b/manual/install.texi @@ -2,6 +2,7 @@ @c Makeinfo ignores it when processing the file from the include. @setfilename INSTALL @include macros.texi +@include pkgvers.texi @node Installation, Maintenance, Library Summary, Top @c %MENU% How to install the GNU C Library @@ -154,6 +155,11 @@ if the used tools support it. By using @samp{--without-tls} this can be prevented though there generally is no reason since it creates compatibility problems. +@item --enable-hardcoded-path-in-tests +By default, dynamic tests are linked to run with the installed C library. +This option hardcodes the newly built C library path in dynamic tests +so that they can be invoked directly. + @item --build=@var{build-system} @itemx --host=@var{host-system} These options are for cross-compiling. If you specify both options and @@ -173,6 +179,19 @@ the appropriate compiler flags (@samp{-mcpu=i386} will do the trick) to @var{CFLAGS}. If you specify just @samp{--build}, @code{configure} will get confused. + +@item --with-pkgversion=@var{version} +Specify a description, possibly including a build number or build +date, of the binaries being built, to be included in +@option{--version} output from programs installed with @theglibc{}. +For example, @option{--with-pkgversion='FooBar GNU/Linux glibc build +123'}. The default value is @samp{GNU libc}. + +@item --with-bugurl=@var{url} +Specify the URL that users should visit if they wish to report a bug, +to be included in @option{--help} output from programs installed with +@theglibc{}. The default value refers to the main bug-reporting +information for @theglibc{}. @end table To build the library and related programs, type @code{make}. This will @@ -458,7 +477,8 @@ remain unfixed for all eternity, if not longer. It is a good idea to verify that the problem has not already been reported. Bugs are documented in two places: The file @file{BUGS} -describes a number of well known bugs and the bug tracking system has a +describes a number of well known bugs and the central @glibcadj{} +bug tracking system has a WWW interface at @url{http://sourceware.org/bugzilla/}. The WWW interface gives you access to open and closed reports. A closed report @@ -483,7 +503,7 @@ library, you really only need to narrow it down to one library function call, if possible. This should not be too difficult. The final step when you have a simple test case is to report the bug. -Do this using the WWW interface to the bug database. +Do this at @value{REPORT_BUGS_TO}. If you are not sure how a function should behave, and this manual doesn't tell you, that's a bug in the manual. Report that too! If the |