| Frequently Asked Question on GNU C Library |
| |
| As every FAQ this one also tries to answer questions the user might have |
| when using the package. Please make sure you read this before sending |
| questions or bug reports to the maintainers. |
| |
| The GNU C Library is very complex. The building process exploits the |
| features available in tools generally available. But many things can |
| only be done using GNU tools. Also the code is sometimes hard to |
| understand because it has to be portable but on the other hand must be |
| fast. But you need not understand the details to use GNU C Library. |
| This will only be necessary if you intend to contribute or change it. |
| |
| If you have any questions you think should be answered in this document, |
| please let me know. |
| |
| --drepper@cygnus.com |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q1] ``What systems does the GNU C Library run on?'' |
| |
| [Q2] ``What compiler do I need to build GNU libc?'' |
| |
| [Q3] ``When starting make I get only error messages. |
| What's wrong?'' |
| |
| [Q4] ``After I changed configure.in I get `Autoconf version X.Y. |
| or higher is required for this script'. What can I do?'' |
| |
| [Q5] ``Do I need a special linker or archiver?'' |
| |
| [Q6] ``Do I need some more things to compile GNU C Library?'' |
| |
| [Q7] ``When I run `nm -u libc.so' on the produced library I still |
| find unresolved symbols? Can this be ok?'' |
| |
| [Q8] ``Can I replace the libc on my Linux system with GNU libc?'' |
| |
| [Q9] ``I expect GNU libc to be 100% source code compatible with |
| the old Linux based GNU libc. Why isn't it like this?'' |
| |
| [Q10] ``Why does getlogin() always return NULL on my Linux box?'' |
| |
| [Q11] ``Where are the DST_* constants found in <sys/time.h> on many |
| systems?'' |
| |
| [Q12] ``The `gencat' utility cannot process the input which are |
| successfully used on my Linux libc based system. Why?'' |
| |
| [Q13] ``How do I configure GNU libc so that the essential libraries |
| like libc.so go into /lib and the other into /usr/lib?'' |
| |
| [Q14] ``When linking with the new libc I get unresolved symbols |
| `crypt' and `setkey'. Why aren't these functions in the |
| libc anymore?'' |
| |
| [Q15] ``What are these `add-ons'?'' |
| |
| [Q16] ``When I use GNU libc on my Linux system by linking against |
| to libc.so which comes with glibc all I get is a core dump.'' |
| |
| [Q17] ``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?'' |
| |
| [Q18] ``The prototypes for `connect', `accept', `getsockopt', |
| `setsockopt', `getsockname', `getpeername', `send', |
| `sendto', and `recvfrom' are different in GNU libc than |
| on any other system I saw. This is a bug, isn't it?'' |
| |
| [Q19] ``My XXX kernel emulates a floating-point coprocessor for me. |
| Should I enable --with-fp?'' |
| |
| [Q20] ``How can I compile gcc 2.7.2.1 from the gcc source code using |
| glibc 2.x? |
| |
| [Q21] ``On Linux I've got problems with the declarations in Linux |
| kernel headers.'' |
| |
| [Q22] ``When I try to compile code which uses IPv6 header and |
| definitions on my Linux 2.x.y system I am in trouble. |
| Nothing seems to work.'' |
| |
| [Q23] ``When compiling GNU libc I get lots of errors saying functions |
| in glibc are duplicated in libgcc.'' |
| |
| [Q24] ``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.'' |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q1] ``What systems does the GNU C Library run on?'' |
| |
| [A1] {UD} This is difficult to answer. The file `README' lists the |
| architectures GNU libc is known to run *at some time*. This does not |
| mean that it still can be compiled and run on them in the moment. |
| |
| The systems glibc is known to work on in the moment and most probably |
| in the future are: |
| |
| *-*-gnu GNU Hurd |
| i[3456]86-*-linux-gnu Linux-2.0 on Intel |
| m68k-*-linux-gnu Linux-2.0 on Motorola 680x0 |
| alpha-*-linux-gnu Linux-2.0 on DEC Alpha |
| |
| Other Linux platforms are also on the way to be supported but I need |
| some success reports first. |
| |
| If you have a system not listed above (or in the `README' file) and |
| you are really interested in porting it, contact |
| |
| <bug-glibc@prep.ai.mit.edu> |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q2] ``What compiler do I need to build GNU libc?'' |
| |
| [A2] {UD} It is (almost) impossible to compile GNU C Library using a |
| different compiler than GNU CC. A lot of extensions of GNU CC are |
| used to increase the portability and speed. |
| |
| But this does not mean you have to use GNU CC for using the GNU C |
| Library. In fact you should be able to use the native C compiler |
| because the success only depends on the binutils: the linker and |
| archiver. |
| |
| The GNU CC is found like all other GNU packages on |
| ftp://prep.ai.mit.edu/pub/gnu |
| or better one of the many mirror sites. |
| |
| You always should try to use the latest official release. Older |
| versions might not have all the features GNU libc could use. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q3] ``When starting `make' I get only errors messages. |
| What's wrong?'' |
| |
| [A3] {UD} You definitely need GNU make to translate GNU libc. No |
| other make program has the needed functionality. |
| |
| Versions before 3.74 have bugs which prevent correct execution so you |
| should upgrade to the latest version before starting the compilation. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q4] ``After I changed configure.in I get `Autoconf version X.Y. |
| or higher is required for this script'. What can I do?'' |
| |
| [A4] {UD} You have to get the specified autoconf version (or a later) |
| from your favourite mirror of prep.ai.mit.edu. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q5] ``Do I need a special linker or archiver?'' |
| |
| [A5] {UD} If your native versions are not too buggy you can probably |
| work with them. But GNU libc works best with GNU binutils. |
| |
| On systems where the native linker does not support weak symbols you |
| will not get a really ISO C compliant C library. Generally speaking |
| you should use the GNU binutils if they provide at least the same |
| functionality as your system's tools. |
| |
| Always get the newest release of GNU binutils available. |
| Older releases are known to have bugs that affect building the GNU C |
| Library. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q6] ``Do I need some more things to compile GNU C Library?'' |
| |
| [A6] {UD} Yes, there are some more :-). |
| |
| * GNU gettext; the GNU libc is internationalized and partly localized. |
| For bringing the messages for the different languages in the needed |
| form the tools from the GNU gettext package are necessary. See |
| ftp://prep.ai.mit.edu/pub/gnu or better any mirror site. |
| |
| * lots of diskspace (for i?86-linux this means, e.g., ~70MB). |
| |
| You should avoid compiling on a NFS mounted device. This is very |
| slow. |
| |
| * plenty of time (approx 1h for i?86-linux on i586@133 or 2.5h on |
| i486@66 or 4.5h on i486@33), both for shared and static only). |
| For Hurd systems times are much higher. |
| |
| For Atari Falcon (Motorola 68030 @ 16 Mhz, 14 Mb memory) James Troup |
| <J.J.Troup@comp.brad.ac.uk> reports for a full build (shared, static, |
| and profiled) a compile time of 45h34m. |
| |
| If you have some more measurements let me know. |
| |
| * When compiling for Linux: |
| |
| + the header files of the Linux kernel must be available in the |
| search path of the CPP as <linux/*.h> and <asm/*.h>. |
| |
| * Some files depend on special tools. E.g., files ending in .gperf |
| need a `gperf' program. The GNU version (part of libg++) is known |
| to work while some vendor versions do not. |
| |
| You should not need these tools unless you change the source files. |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q7] ``When I run `nm -u libc.so' on the produced library I still |
| find unresolved symbols? Can this be ok?'' |
| |
| [A7] {UD} Yes, this is ok. There can be several kinds of unresolved |
| symbols: |
| |
| * magic symbols automatically generated by the linker. Names are |
| often like __start_* and __stop_* |
| |
| * symbols starting with _dl_* come from the dynamic linker |
| |
| * symbols resolved by using libgcc.a |
| (__udivdi3, __umoddi3, or similar) |
| |
| * weak symbols, which need not be resolved at all |
| (currently fabs among others; this gets resolved if the program |
| is linked against libm, too.) |
| |
| Generally, you should make sure you find a real program which produces |
| errors while linking before deciding there is a problem. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q8] ``Can I replace the libc on my Linux system with GNU libc?'' |
| |
| [A8] {UD} You cannot replace any existing libc for Linux with GNU |
| libc. There are different versions of C libraries and you can run |
| libcs with different major version independently. |
| |
| For Linux there are today two libc versions: |
| libc-4 old a.out libc |
| libc-5 current ELF libc |
| |
| GNU libc will have the major number 6 and therefore you can have this |
| additionally 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. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q9] ``I expect GNU libc to be 100% source code compatible with |
| the old Linux based GNU libc. Why isn't it like this?'' |
| |
| [A9] {DMT,UD} Not every extension in Linux libc's history was well |
| thought-out. In fact it had a lot of problems with standards compliance |
| and with cleanliness. With the introduction of a new version number these |
| errors now can be corrected. Here is a list of the known source code |
| incompatibilities: |
| |
| * _GNU_SOURCE: glibc does not automatically define _GNU_SOURCE. Thus, |
| if a program depends on GNU extensions or some other non-standard |
| functionality, it is necessary to compile it with C compiler option |
| -D_GNU_SOURCE, or better, to put `#define _GNU_SOURCE' at the beginning |
| of your source files, before any C library header files are included. |
| This difference normally manifests itself in the form of missing |
| prototypes and/or data type definitions. Thus, if you get such errors, |
| the first thing you should do is try defining _GNU_SOURCE and see if |
| that makes the problem go away. |
| |
| For more information consult the file `NOTES' part of the GNU C |
| library sources. |
| |
| * reboot(): GNU libc sanitizes the interface of reboot() to be more |
| compatible with the interface used on other OSes. In particular, |
| reboot() as implemented in glibc takes just one argument. This argument |
| corresponds to the third argument of the Linux reboot system call. |
| That is, a call of the form reboot(a, b, c) needs to be changed into |
| reboot(c). |
| Beside this the header <sys/reboot.h> defines the needed constants |
| for the argument. These RB_* constants should be used instead of the |
| cryptic magic numbers. |
| |
| * swapon(): the interface of this function didn't changed, but the |
| prototype is in a separate header file <sys/swap.h>. For the additional |
| argument of swapon() you should use the SWAP_* constants from |
| <linux/swap.h>, which get defined when <sys/swap.h> is included. |
| |
| * errno: If a program uses variable "errno", then it _must_ include header |
| file <errno.h>. The old libc often (erroneously) declared this variable |
| implicitly as a side-effect of including other libc header files. glibc |
| is careful to avoid such namespace pollution, which, in turn, means that |
| you really need to include the header files that you depend on. This |
| difference normally manifests itself in the form of the compiler |
| complaining about the references of the undeclared symbol "errno". |
| |
| * Linux-specific syscalls: All Linux system calls now have appropriate |
| library wrappers and corresponding declarations in various header files. |
| This is because the syscall() macro that was traditionally used to |
| work around missing syscall wrappers are inherently non-portable and |
| error-prone. The following tables lists all the new syscall stubs, |
| the header-file declaring their interface and the system call name. |
| |
| syscall name: wrapper name: declaring header file: |
| ------------- ------------- ---------------------- |
| bdflush bdflush <sys/kdaemon.h> |
| create_module create_module <sys/module.h> |
| delete_module delete_module <sys/module.h> |
| get_kernel_syms get_kernel_syms <sys/module.h> |
| init_module init_module <sys/module.h> |
| syslog ksyslog_ctl <sys/klog.h> |
| |
| * lpd: Older versions of lpd depend on a routine called _validuser(). |
| The library does not provide this function, but instead provides |
| __ivaliduser() which has a slightly different interfaces. Simply |
| upgrading to a newer lpd should fix this problem (e.g., the 4.4BSD |
| lpd is known to be working). |
| |
| * resolver functions/BIND: like on many other systems the functions of |
| the resolver library are not included in the libc itself. There is |
| a separate library libresolv. If you find some symbols starting with |
| `res_*' undefined simply add -lresolv to your call of the linker. |
| |
| * the `signal' function's behaviour corresponds to the BSD semantic and |
| not the SysV semantic as it was in libc-5. The interface on all GNU |
| systems shall be the same and BSD is the semantic of choice. To use |
| the SysV behaviour simply use `sysv_signal'. The major difference is |
| that the SysV implementation sets the SA_ONESHOT flag and so the handler |
| gets removed after the first call. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q10] ``Why does getlogin() always return NULL on my Linux box?'' |
| |
| [A10] {UD} The GNU C library has a format for the UTMP and WTMP file |
| which differs from what your system currently has. It was extended to |
| fulfill the needs of the next years when IPv6 is introduced. So the |
| record size is different, fields might have a different position and |
| so reading the files written by functions from the one library cannot |
| be read by functions from the other library. Sorry, but this is what |
| a major release is for. It's better to have a cut now than having no |
| means to support the new techniques later. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q11] ``Where are the DST_* constants found in <sys/time.h> on many |
| systems?'' |
| |
| [A11] {UD} These constants come from the old BSD days and are not used |
| today anymore (even the Linux based glibc does not implement the handling |
| although the constants are defined). |
| |
| Instead GNU libc contains the zone database handling and compatibility |
| code for POSIX TZ environment variable handling. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q12] ``The `gencat' utility cannot process the input which are |
| successfully used on my Linux libc based system. Why?'' |
| |
| [A12] {UD} Unlike the author of the `gencat' program which is distributed |
| with Linux libc I have read the underlying standards before writing the |
| code. It is completely compatible with the specification given in |
| X/Open Portability Guide. |
| |
| 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/ |
| } |
| ----------------------------------------------------------------------- |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q13] ``How do I configure GNU libc so that the essential libraries |
| like libc.so go into /lib and the other into /usr/lib?'' |
| |
| [A13] {UD,AJ} Like all other GNU packages GNU libc is configured to |
| use a base directory and install all files relative to this. If you |
| intend to really use GNU libc on your system this base directory is |
| /usr. I.e., you run |
| configure --prefix=/usr <other_options> |
| |
| 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. |
| |
| To install the essential libraries which come with GNU libc in /lib |
| one must explicitly tell this (except on Linux, see below). Autoconf |
| has no option for this so you have to use the file where all user |
| supplied additional information should go in: `configparms' (see the |
| `INSTALL' file). Therefore the `configparms' file should contain: |
| |
| slibdir=/lib |
| sysconfdir=/etc |
| |
| The first line specifies the directory for the essential libraries, |
| the second line the directory for file which are by tradition placed |
| in a directory named /etc. |
| |
| No rule without an exception: If you configure for Linux with |
| --prefix=/usr, then slibdir and sysconfdir will automatically be |
| defined as stated above. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q14] ``When linking with the new libc I get unresolved symbols |
| `crypt' and `setkey'. Why aren't these functions in the |
| libc anymore?'' |
| |
| [A14] {UD} Remember the US restrictions of exporting cryptographic |
| programs and source code. Until this law gets abolished we cannot |
| ship the cryptographic function together with the libc. |
| |
| But of course we provide the code and there is an very easy way to use |
| this code. First get the extra package. People in the US way get it |
| from the same place they got the 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 failed to link with -lcrypt. The crypto |
| functions are in a separate library to make it possible to export GNU |
| libc binaries from the US. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q15] ``What are these `add-ons'?'' |
| |
| [A15] {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 Q14). |
| |
| To ease the use as part of GNU libc the installer just has to unpack |
| the package and tell the configuration script about these additional |
| subdirectories using the --enable-add-ons option. When you add the |
| crypt add-on you just have to use |
| |
| configure --enable-add-ons=crypt,XXX ... |
| |
| where XXX are possible other add-ons and ... means the rest of the |
| normal option list. |
| |
| You can use add-ons also to overwrite some files in glibc. The add-on |
| system dependent subdirs are search first. It is also possible to add |
| banner files (use a file named `Banner') or create shared libraries. |
| |
| Using add-ons has the big advantage that the makefiles of the GNU libc |
| can be used. Only some few stub rules must be written to get |
| everything running. Even handling of architecture dependent |
| compilation is provided. The GNU libc's sysdeps/ directory shows how |
| to use this feature. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q16] ``When I use GNU libc on my Linux system by linking against |
| to libc.so which comes with glibc all I get is a core dump.'' |
| |
| [A16] {UD} It is not enough to simply link against the GNU libc |
| library itself. The GNU C library comes with its own dynamic linker |
| which really conforms to the ELF API standard. This dynamic linker |
| must be used. |
| |
| Normally this is done by the compiler. The gcc will use |
| |
| -dynamic-linker /lib/ld-linux.so.1 |
| |
| unless the user specifies her/himself a -dynamic-linker argument. But |
| this is not the correct name for the GNU dynamic linker. The correct |
| name is /lib/ld.so.1 which is the name specified in the SVr4 ABi. |
| |
| 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.so.1' (or to ld-linux.so.2, see below) |
| |
| - remove all expression `%{...:-lgmon}'; there is no libgmon in glibc |
| |
| |
| Things are getting 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. Here is for |
| example the gcc-2.7.2 specs file when GNU libc is installed at |
| /usr: |
| |
| ----------------------------------------------------------------------- |
| *asm: |
| %{V} %{v:%{!V:-V}} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} |
| |
| *asm_final: |
| %{pipe:-} |
| |
| *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: |
| . ; |
| |
| ----------------------------------------------------------------------- |
| |
| The above is currently correct for ix86/Linux. Because of |
| compatibility issues on this platform the dynamic linker must have |
| a different name: ld-linux.so.2. So you have to replace |
| |
| %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld-linux.so.2} |
| by |
| %{!dynamic-linker:-dynamic-linker=/home/gnu/lib/ld.so.1} |
| |
| in the above example specs file to make it work for other systems. |
| |
| Version 2.7.2.2 does and future versions of GCC will automatically |
| provide the correct specs. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q17] ``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?'' |
| |
| [A17] {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 ld.so.1 libc.a ) |
| |
| or in ix86/Linux and alpha/Linux: |
| |
| GROUP ( libc.so.6 ld-linux.so.2 libc.a ) |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q18] ``The prototypes for `connect', `accept', `getsockopt', |
| `setsockopt', `getsockname', `getpeername', `send', |
| `sendto', and `recvfrom' are different in GNU libc from |
| any other system I saw. This is a bug, isn't it?'' |
| |
| [A18] {UD} No, this is no bug. This version of the GNU libc already |
| follows the to-be-released POSIX.1g standard. In this standard |
| the type `size_t' is used for all parameters which describe a size. |
| So better change now. |
| |
| This change is critical for system which have |
| sizeof (int) != sizeof (size_t) |
| like the Alpha. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q19] ``My XXX kernel emulates a floating-point coprocessor for me. |
| Should I enable --with-fp?'' |
| |
| [A19] {UD} As `configure --help' shows the default value is `yes' and |
| this should not be changed unless the FPU instructions would be |
| invalid. I.e., an emulated FPU is for the libc as good as a real one. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q20] ``How can I compile gcc 2.7.2.1 from the gcc source code using |
| glibc 2.x? |
| |
| [A20] {AJ} There's only support for glibc 2.0 in gcc 2.7.2.2 or later. |
| For 2.7.2.2 you should use the following patch and configure for |
| e.g. i486-linux. |
| ----------------------------------------------------------------------- |
| --- configure Tue Feb 11 15:57:17 1997 |
| +++ configure Wed Feb 12 23:09:29 1997 |
| @@ -1021,7 +1021,7 @@ |
| gnu_ld=yes |
| # GNU libc version 2 does not supply these; |
| # we want them from GCC. |
| - extra_parts="crtbegin.o crtend.o" |
| + extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o" |
| ;; |
| i[3456]86-go32-msdos | i[3456]86-*-go32) |
| cpu_type=i386 |
| ----------------------------------------------------------------------- |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q21] ``On Linux I've got problems with the declarations in Linux |
| kernel headers.'' |
| |
| [A21] {UD,AJ} On Linux, the use of kernel headers is reduced to a very |
| minimum. Besides giving Linus the possibility to change the headers |
| more freely it has another reason: user level programs now do not |
| always use the same types like the kernel does. |
| |
| I.e., the libc abstracts the use of types. E.g., the sigset_t type is |
| in the kernel 32 or 64 bits wide. In glibc it is 1024 bits wide, in |
| preparation for future development. The reasons are obvious: we don't |
| want to have a new major release when the Linux kernel gets these |
| functionality. Consult the headers for more information about the changes. |
| |
| Therefore you shouldn't include Linux kernel header files directly if |
| glibc has defined a replacement. Otherwise you might get undefined |
| results because of type conflicts. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q22] ``When I try to compile code which uses IPv6 header and |
| definitions on my Linux 2.x.y system I am in trouble. |
| Nothing seems to work.'' |
| |
| [A22] {UD} The problem is that the IPv6 development still has not reached |
| a point where it is stable. There are still lots of incompatible changes |
| made and the libc headers have to follow. |
| |
| Currently (as of 970401) according to Philip Blundell <pjb27@cam.ac.uk> |
| the required kernel version is 2.1.30. |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q23] ``When compiling GNU libc I get lots of errors saying functions |
| in glibc are duplicated in libgcc.'' |
| |
| [A23] {EY} This is *exactly* the same problem that I was having. The |
| problem was due to the fact that the autoconfigure didn't correctly |
| detect that 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. |
| |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| [Q24] ``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.'' |
| |
| [A24] The glibc NIS+ implementation uses a /var/nis/NIS_COLD_START |
| file for storing information about the NIS+ server and their |
| public keys, because the nis.conf file do not contain all |
| necessary information. You have to copy a NIS_COLD_START file |
| from a Solaris client (the NIS_COLD_START file is byte order |
| independend) or generate it new with nisinit from the nis-tools |
| (look at http://www-vt.uni-paderborn.de/~kukuk/linux/nisplus.html). |
| |
| |
| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ |
| |
| Answers were given by: |
| {UD} Ulrich Drepper, <drepper@cygnus.com> |
| {DMT} David Mosberger-Tang, <davidm@AZStarNet.com> |
| {RM} Roland McGrath, <roland@gnu.ai.mit.edu> |
| {HJL} H.J. Lu, <hjl@gnu.ai.mit.edu> |
| {AJ} Andreas Jaeger, <aj@arthur.rhein-neckar.de> |
| {EY} Eric Youngdale, <eric@andante.jic.com> |
| |
| Local Variables: |
| mode:text |
| End: |