+1.10. What are these `add-ons'?
+
+{UD} To avoid complications with export rules or external source code some
+optional parts of the libc are distributed as separate packages (e.g., the
+crypt package, see question 2.5).
+
+To use these packages as part of GNU libc, just unpack the tarfiles in the
+libc source directory and tell the configuration script about them using the
+--enable-add-ons option. If you give just --enable-add-ons configure tries
+to find all the add-on packages in your source tree. This may not work. If
+it doesn't, or if you want to select only a subset of the add-ons, give a
+comma-separated list of the add-ons to enable:
+
+ configure --enable-add-ons=crypt,linuxthreads
+
+for example.
+
+Add-ons can add features (including entirely new shared libraries), override
+files, provide support for additional architectures, and just about anything
+else. The existing makefiles do most of the work; only some few stub rules
+must be written to get everything running.
+
+
+1.11. My XXX kernel emulates a floating-point coprocessor for me.
+ Should I enable --with-fp?
+
+{ZW} An emulated FPU is just as good as a real one, as far as the C library
+is concerned. You only need to say --without-fp if your machine has no way
+to execute floating-point instructions.
+
+People who are interested in squeezing the last drop of performance
+out of their machine may wish to avoid the trap overhead, but this is
+far more trouble than it's worth: you then have to compile
+*everything* this way, including the compiler's internal libraries
+(libgcc.a for GNU C), because the calling conventions change.
+
+
+1.12. When compiling GNU libc I get lots of errors saying functions
+ in glibc are duplicated in libgcc.
+
+{EY} This is *exactly* the same problem that I was having. The problem was
+due to the fact that configure didn't correctly detect that the linker flag
+--no-whole-archive was supported in my linker. In my case it was because I
+had run ./configure with bogus CFLAGS, and the test failed.
+
+One thing that is particularly annoying about this problem is that once this
+is misdetected, running configure again won't fix it unless you first delete
+config.cache.
+
+{UD} Starting with glibc-2.0.3 there should be a better test to avoid some
+problems of this kind. The setting of CFLAGS is checked at the very
+beginning and if it is not usable `configure' will bark.
+
+
+1.13. Why do I get messages about missing thread functions when I use
+ librt? I don't even use threads.
+
+{UD} In this case you probably mixed up your installation. librt uses
+threads internally and has implicit references to the thread library.
+Normally these references are satisfied automatically but if the thread
+library is not in the expected place you must tell the linker where it is.
+When using GNU ld it works like this:
+
+ gcc -o foo foo.c -Wl,-rpath-link=/some/other/dir -lrt
+
+The `/some/other/dir' should contain the thread library. `ld' will use the
+given path to find the implicitly referenced library while not disturbing
+any other link path.
+
+
+1.14. What's the problem with configure --enable-omitfp?
+
+{AJ} When --enable-omitfp is set the libraries are built without frame
+pointers. Some compilers produce buggy code for this model and therefore we
+don't advise using it at the moment.
+
+If you use --enable-omitfp, you're on your own. If you encounter problems
+with a library that was build this way, we advise you to rebuild the library
+without --enable-omitfp. If the problem vanishes consider tracking the
+problem down and report it as compiler failure.
+
+Since a library build with --enable-omitfp is undebuggable on most systems,
+debuggable libraries are also built - you can use it by appending "_g" to
+the library names.
+
+The compilation of these extra libraries and the compiler optimizations slow
+down the build process and need more disk space.
+
+\f
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+
+2. Installation and configuration issues
+
+2.1. Can I replace the libc on my Linux system with GNU libc?
+
+{UD} You cannot replace any existing libc for Linux with GNU libc. It is
+binary incompatible and therefore has a different major version. You can,
+however, install it alongside your existing libc.
+
+For Linux there are three major libc versions:
+ libc-4 a.out libc
+ libc-5 original ELF libc
+ libc-6 GNU libc
+
+You can have any combination of these three installed. For more information
+consult documentation for shared library handling. The Makefiles of GNU
+libc will automatically generate the needed symbolic links which the linker
+will use.
+
+
+2.2. How do I configure GNU libc so that the essential libraries
+ like libc.so go into /lib and the other into /usr/lib?
+
+{UD,AJ} Like all other GNU packages GNU libc is designed to use a base
+directory and install all files relative to this. The default is
+/usr/local, because this is safe (it will not damage the system if installed
+there). If you wish to install GNU libc as the primary C library on your
+system, set the base directory to /usr (i.e. run configure --prefix=/usr
+<other_options>). Note that this can damage your system; see question 2.3 for
+details.
+
+Some systems like Linux have a filesystem standard which makes a difference
+between essential libraries and others. Essential libraries are placed in
+/lib because this directory is required to be located on the same disk
+partition as /. The /usr subtree might be found on another
+partition/disk. If you configure for Linux with --prefix=/usr, then this
+will be done automatically.
+
+To install the essential libraries which come with GNU libc in /lib on
+systems other than Linux one must explicitly request it. Autoconf has no
+option for this so you have to use a `configparms' file (see the `INSTALL'
+file for details). It should contain:
+
+slibdir=/lib
+sysconfdir=/etc
+
+The first line specifies the directory for the essential libraries, the
+second line the directory for system configuration files.
+
+
+2.3. How should I avoid damaging my system when I install GNU libc?
+
+{ZW} If you wish to be cautious, do not configure with --prefix=/usr. If
+you don't specify a prefix, glibc will be installed in /usr/local, where it
+will probably not break anything. (If you wish to be certain, set the
+prefix to something like /usr/local/glibc2 which is not used for anything.)
+
+The dangers when installing glibc in /usr are twofold:
+
+* glibc will overwrite the headers in /usr/include. Other C libraries
+ install a different but overlapping set of headers there, so the
+ effect will probably be that you can't compile anything. You need to
+ rename /usr/include out of the way first. (Do not throw it away; you
+ will then lose the ability to compile programs against your old libc.)
+
+* None of your old libraries, static or shared, can be used with a
+ different C library major version. For shared libraries this is not a
+ problem, because the filenames are different and the dynamic linker
+ will enforce the restriction. But static libraries have no version
+ information. You have to evacuate all the static libraries in
+ /usr/lib to a safe location.
+
+The situation is rather similar to the move from a.out to ELF which
+long-time Linux users will remember.
+
+
+2.4. Do I need to use GNU CC to compile programs that will use the
+ GNU C Library?
+
+{ZW} In theory, no; the linker does not care, and the headers are supposed
+to check for GNU CC before using its extensions to the C language.
+
+However, there are currently no ports of glibc to systems where another
+compiler is the default, so no one has tested the headers extensively
+against another compiler. You may therefore encounter difficulties. If you
+do, please report them as bugs.
+
+Also, in several places GNU extensions provide large benefits in code
+quality. For example, the library has hand-optimized, inline assembly
+versions of some string functions. These can only be used with GCC. See
+question 3.8 for details.
+
+
+2.5. When linking with the new libc I get unresolved symbols
+ `crypt' and `setkey'. Why aren't these functions in the
+ libc anymore?
+
+{UD} The US places restrictions on exporting cryptographic programs and
+source code. Until this law gets abolished we cannot ship the cryptographic
+functions together with glibc.
+
+The functions are available, as an add-on (see question 1.10). People in the US
+may get it from the same place they got GNU libc from. People outside the
+US should get the code from ftp://ftp.ifi.uio.no/pub/gnu, or another archive
+site outside the USA. The README explains how to install the sources.
+
+If you already have the crypt code on your system the reason for the failure
+is probably that you did not link with -lcrypt. The crypto functions are in
+a separate library to make it possible to export GNU libc binaries from the
+US.
+
+
+2.6. When I use GNU libc on my Linux system by linking against
+ the libc.so which comes with glibc all I get is a core dump.
+
+{UD} On Linux, gcc sets the dynamic linker to /lib/ld-linux.so.1 unless the
+user specifies a -dynamic-linker argument. This is the name of the libc5
+dynamic linker, which does not work with glibc.
+
+For casual use of GNU libc you can just specify
+ -dynamic-linker=/lib/ld-linux.so.2
+
+which is the glibc dynamic linker, on Linux systems. On other systems the
+name is /lib/ld.so.1.
+
+To change your environment to use GNU libc for compiling you need to change
+the `specs' file of your gcc. This file is normally found at
+
+ /usr/lib/gcc-lib/<arch>/<version>/specs
+
+In this file you have to change a few things:
+
+- change `ld-linux.so.1' to `ld-linux.so.2'
+
+- remove all expression `%{...:-lgmon}'; there is no libgmon in glibc
+
+- fix a minor bug by changing %{pipe:-} to %|
+
+Here is what the gcc-2.7.2 specs file should look like when GNU libc is
+installed at /usr:
+
+-----------------------------------------------------------------------
+*asm:
+%{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
+
+*asm_final:
+%|
+
+*cpp:
+%{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
+
+*cc1:
+%{profile:-p}
+
+*cc1plus:
+
+
+*endfile:
+%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s
+
+*link:
+-m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} %{static:-static}}}
+
+*lib:
+%{!shared: %{pthread:-lpthread} %{profile:-lc_p} %{!profile: -lc}}
+
+*libgcc:
+-lgcc
+
+*startfile:
+%{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:%{profile:gcrt1.o%s} %{!profile:crt1.o%s}}}} crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}
+
+*switches_need_spaces:
+
+
+*signed_char:
+%{funsigned-char:-D__CHAR_UNSIGNED__}
+
+*predefines:
+-D__ELF__ -Dunix -Di386 -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386)
+
+*cross_compile:
+0
+
+*multilib:
+. ;
+
+-----------------------------------------------------------------------
+
+Things get a bit more complicated if you have GNU libc installed in some
+other place than /usr, i.e., if you do not want to use it instead of the old
+libc. In this case the needed startup files and libraries are not found in
+the regular places. So the specs file must tell the compiler and linker
+exactly what to use.
+
+Version 2.7.2.3 does and future versions of GCC will automatically
+provide the correct specs.
+
+
+2.7. Looking through the shared libc file I haven't found the
+ functions `stat', `lstat', `fstat', and `mknod' and while
+ linking on my Linux system I get error messages. How is
+ this supposed to work?
+
+{RM} Believe it or not, stat and lstat (and fstat, and mknod) are supposed
+to be undefined references in libc.so.6! Your problem is probably a missing
+or incorrect /usr/lib/libc.so file; note that this is a small text file now,
+not a symlink to libc.so.6. It should look something like this:
+
+GROUP ( libc.so.6 libc_nonshared.a )
+
+
+2.8. How can I compile gcc 2.7.2.1 from the gcc source code using
+ glibc 2.x?
+
+{AJ} There's only correct support for glibc 2.0.x in gcc 2.7.2.3 or later.
+But you should get at least gcc 2.8.1 or egcs 1.0.2 (or later versions)
+instead.
+
+
+2.9. The `gencat' utility cannot process the catalog sources which
+ were used on my Linux libc5 based system. Why?
+
+{UD} The `gencat' utility provided with glibc complies to the XPG standard.
+The older Linux version did not obey the standard, so they are not
+compatible.
+
+To ease the transition from the Linux version some of the non-standard
+features are also present in the `gencat' program of GNU libc. This mainly
+includes the use of symbols for the message number and the automatic
+generation of header files which contain the needed #defines to map the
+symbols to integers.
+
+Here is a simple SED script to convert at least some Linux specific catalog
+files to the XPG4 form:
+
+-----------------------------------------------------------------------
+# Change catalog source in Linux specific format to standard XPG format.
+# Ulrich Drepper <drepper@cygnus.com>, 1996.
+#
+/^\$ #/ {
+ h
+ s/\$ #\([^ ]*\).*/\1/
+ x
+ s/\$ #[^ ]* *\(.*\)/\$ \1/
+}
+
+/^# / {
+ s/^# \(.*\)/\1/
+ G
+ s/\(.*\)\n\(.*\)/\2 \1/
+}
+-----------------------------------------------------------------------
+
+
+2.10. Programs using libc have their messages translated, but other
+ behavior is not localized (e.g. collating order); why?
+
+{ZW} Translated messages are automatically installed, but the locale
+database that controls other behaviors is not. You need to run localedef to
+install this database, after you have run `make install'. For example, to
+set up the French Canadian locale, simply issue the command
+
+ localedef -i fr_CA -f ISO-8859-1 fr_CA
+
+Please see localedata/README in the source tree for further details.
+
+
+2.11. I have set up /etc/nis.conf, and the Linux libc 5 with NYS
+ works great. But the glibc NIS+ doesn't seem to work.
projects / kopensolaris-gnu / glibc.git / blobdiff