+In some situations (especially when testing a new library release) it might
+be possible that a symbol changed size when that should not have happened.
+So in case of doubt report such a warning message as a problem.
+
+
+2.20. What do I need for C++ development?
+
+{HJ,AJ} You need either egcs 1.0.2 or gcc-2.8.1 with libstdc++ 2.8.1 (or
+more recent versions). libg++ 2.7.2 (and the Linux Versions 2.7.2.x) doesn't
+work very well with the GNU C library due to vtable thunks. If you're
+upgrading from glibc 2.0.x to 2.1 you have to recompile libstdc++ since the
+library compiled for 2.0 is not compatible due to the new Large File Support
+(LFS) in version 2.1.
+
+
+2.21. Even statically linked programs need some shared libraries
+ which is not acceptable for me. What can I do?
+
+{AJ} NSS (for details just type `info libc "Name Service Switch"') won't
+work properly without shared libraries. NSS allows using different services
+(e.g. NIS, files, db, hesiod) by just changing one configuration file
+(/etc/nsswitch.conf) without relinking any programs. The only disadvantage
+is that now static libraries need to access shared libraries. This is
+handled transparently by the GNU C library.
+
+A solution is to configure glibc with --enable-static-nss. In this case you
+can create a static binary that will use only the services dns and files
+(change /etc/nsswitch.conf for this). You need to link explicitly against
+all these services. For example:
+
+ gcc -static test-netdb.c -o test-netdb.c \
+ -lc -lnss_files -lnss_dns -lresolv
+
+The problem with this approach is that you've got to link every static
+program that uses NSS routines with all those libraries.
+
+{UD} In fact, one cannot say anymore that a libc compiled with this
+option is using NSS. There is no switch anymore. Therefore it is
+*highly* recommended *not* to use --enable-static-nss since this makes
+the behaviour of the programs on the system inconsistent.
+
+\f
+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+
+3. Source and binary incompatibilities, and what to do about them
+
+3.1. I expect GNU libc to be 100% source code compatible with
+ the old Linux based GNU libc. Why isn't it like this?
+
+{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 can
+now be corrected. Here is a list of the known source code
+incompatibilities:
+
+* _GNU_SOURCE: glibc does not make the GNU extensions available
+ automatically. If a program depends on GNU extensions or some
+ other non-standard functionality, it is necessary to compile it
+ with the 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' in the GNU C library
+ sources.
+
+* reboot(): GNU libc sanitizes the interface of reboot() to be more
+ compatible with the interface used on other OSes. 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 change, but the
+ prototype is in a separate header file <sys/swap.h>. This header
+ file also provides the SWAP_* constants defined by <linux/swap.h>;
+ you should use them for the second argument to swapon().
+
+* errno: If a program uses the variable "errno", then it _must_
+ include <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 references to an 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 table 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>
+ 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 interface. 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 libc itself. There is a
+ separate library libresolv. If you get undefined symbol errors for
+ symbols starting with `res_*' simply add -lresolv to your linker
+ command line.
+
+* the `signal' function's behavior 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 behavior simply use `sysv_signal', or define _XOPEN_SOURCE.
+ See question 3.7 for details.
+
+
+3.2. Why does getlogin() always return NULL on my Linux box?
+
+{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. The record size is different and
+some fields have different positions. 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.
+
+{MK} There is however a (partial) solution for this problem. Please take a
+look at the file `login/README.utmpd'.
+
+
+3.3. Where are the DST_* constants found in <sys/time.h> on many
+ systems?
+
+{UD} These constants come from the old BSD days and are not used anymore
+(libc5 does not actually implement the handling although the constants are
+defined).
+
+Instead GNU libc contains zone database support and compatibility code for
+POSIX TZ environment variable handling.
+
+
+3.4. 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?
projects / kopensolaris-gnu / glibc.git / blobdiff