Gecko [ v99win.today ]

Name	Size	Permission
glibc-doc.docs	16 B	-rw-r--r--
glibc-doc.links	1.5 KB	-rw-r--r--
glibc-doc.manpages	350 B	-rw-r--r--
glibc-source.install	41 B	-rw-r--r--
glibc-source.lintian-overrides	2.64 KB	-rw-r--r--
libc-alt.fixperms	19 B	-rw-r--r--
libc-alt.install	166 B	-rw-r--r--
libc-alt.lintian-overrides	490 B	-rw-r--r--
libc-alt.postrm	586 B	-rw-r--r--
libc-bin.dirs	34 B	-rw-r--r--
libc-bin.install	722 B	-rw-r--r--
libc-bin.lintian-overrides	1.05 KB	-rw-r--r--
libc-bin.manpages	65 B	-rw-r--r--
libc-bin.postinst	1.25 KB	-rw-r--r--
libc-bin.triggers	440 B	-rw-r--r--
libc-dev-alt.install	633 B	-rw-r--r--
libc-dev-alt.lintian-overrides	157 B	-rw-r--r--
libc-dev-bin.install	39 B	-rw-r--r--
libc-dev-bin.manpages	31 B	-rw-r--r--
libc-dev.install	596 B	-rw-r--r--
libc-dev.install.hurd-i386	642 B	-rw-r--r--
libc-dev.lintian-overrides	150 B	-rw-r--r--
libc-devtools.install	203 B	-rw-r--r--
libc-devtools.lintian-override...	273 B	-rw-r--r--
libc-devtools.manpages	32 B	-rw-r--r--
libc-l10n.install	133 B	-rw-r--r--
libc-otherbuild.fixperms	19 B	-rw-r--r--
libc-otherbuild.install	98 B	-rw-r--r--
libc-otherbuild.lintian-overri...	679 B	-rw-r--r--
libc-otherbuild.postinst	121 B	-rw-r--r--
libc-otherbuild.postrm	118 B	-rw-r--r--
libc-prof.install	27 B	-rw-r--r--
libc-udeb.install	550 B	-rw-r--r--
libc-udeb.install.hurd-i386	630 B	-rw-r--r--
libc-udeb.links.hurd-i386	22 B	-rw-r--r--
libc.NEWS	5.23 KB	-rw-r--r--
libc.README.Debian	5.78 KB	-rw-r--r--
libc.dirs	17 B	-rw-r--r--
libc.docs	26 B	-rw-r--r--
libc.fixperms	19 B	-rw-r--r--
libc.install	158 B	-rw-r--r--
libc.lintian-overrides	586 B	-rw-r--r--
libc.postinst	5.29 KB	-rw-r--r--
libc.postrm	816 B	-rw-r--r--
libc.preinst	14.96 KB	-rw-r--r--
libc.templates	3.2 KB	-rw-r--r--
libc6-prof.README.Debian	587 B	-rw-r--r--
locales-all.NEWS	299 B	-rw-r--r--
locales-all.dirs	15 B	-rw-r--r--
locales-all.install	56 B	-rw-r--r--
locales-all.postinst	243 B	-rw-r--r--
locales-all.prerm	426 B	-rw-r--r--
locales.NEWS	1.12 KB	-rw-r--r--
locales.README.Debian	737 B	-rw-r--r--
locales.config	3.28 KB	-rw-r--r--
locales.dirs	15 B	-rw-r--r--
locales.install	370 B	-rw-r--r--
locales.links	47 B	-rw-r--r--
locales.manpages	312 B	-rw-r--r--
locales.postinst	2.46 KB	-rw-r--r--
locales.postrm	137 B	-rw-r--r--
locales.prerm	381 B	-rw-r--r--
locales.templates	1.05 KB	-rw-r--r--
nscd.dirs	15 B	-rw-r--r--
nscd.init	3.5 KB	-rw-r--r--
nscd.install	60 B	-rw-r--r--
nscd.manpages	63 B	-rw-r--r--
nscd.postrm	111 B	-rw-r--r--

Code Editor : libc.README.Debian

Q1: Why does the Debian libc6-dev package create /usr/include/linux and 
/usr/include/asm directories containing header files from a specific 
kernel, instead of using the "established" convention of making those 
directories into symlinks pointing to the currently installed kernel?

A1: Occasionally, changes in the kernel headers cause problems with
the compilation of libc and of programs that use libc.  To ensure that
users are not affected by these problems, we configure libc to use the
headers from a kernel that is known to work with libc and the programs
that depend on stable kernel headers.

[Note: /usr/include/linux is now in the linux-libc-dev package.]

Q2: What if I want to compile a program that needs a feature from a
later kernel than is used by libc?

A2: In practice, most programs will not have this problem.  However,
depending on the scope of the problem you have several options available:

If the situation is one like "kernel driver development", where all use
of the machine for development is expected to be against a different set
of kernel headers than are supplied with the "stock" libc6-dev, rebuilding
the glibc packages against that particular kernel will create a full set of
libc6 packages that are "compliant" with the new kernel. All development 
done on machines with these packages installed will be done against the 
new kernel. To build libc6-dev against your particular kernel, export the
environment variable LINUX_SOURCE, set to the path to that particular kernel
source directory and then build the package.

If you want this new glibc package to stick against further upgrades, simply 
use dselect and place the packages on HOLD. This will keep them from being 
upgraded against your wishes.

If there is just one particular program/package that needs different headers,
and your kernel of choice is installed in the usual place, you can use the
-I/usr/src/linux/include option on the gcc command line, when compiling that
specific program.

Q3: My program is trying to use a kernel header that is in libc-dev, and
it is causing problems. (or) Why are the kernel headers not the same for
all architectures in Debian, for a given version of libc-dev?

A3: For starters, you should never use kernel headers directly from user
space programs. You cannot be guaranteed a consistent interface across
different versions of the kernel, much less across architectures (even for
the same version of kernel source).

Kernel headers are included with libc-dev _only_ to support those headers
in libc-dev. They are not there for userspace programs to include. If you
need kernel headers, then use one of the provided kernel-headers-x.x.x
packages provided for each architectures, or include the kernel headers
(or just the parts of the headers) you need directly in your source for
compilation. Only this way can you ensure a consistent state.

Q4: Why does Debian's glibc seem to follow the stable CVS branch?

A4: During our development cycle we follow the stable CVS branch so that
we can cause as little disruption as possible, and catch problems easier.
Differences between minor releases of glibc are known to be very large,
contain many changes, and generally affect all architectures differently.
We sync frequently with CVS so that we can take this large amount of
changes in smaller chunks, simplifying the process, and allowing us to
communicate problems to upstream much easier.

Q5: How to setup my own language/regional (locale) setting?

A5: Glibc provides "locale" defined in POSIX.  Locale is a framework
to switch between multiple languages for users who can select to use
their language, country, characters, collation order, etc.  For
example, some program display messages in your own language, if you
set the appropriate locale.  Default locale is C (or POSIX) which
behaves traditional Unix with ASCII message.  For more information,
look locale (5).

If you want to use your own locale, install "locales" package.  With
debconf interface, you can setup which locale is generated, and which
locale is used in default on your machine.

Q6: I get this message when I run a program:
	ld.so: Incorrectly built binary which accesses errno or h_errno directly.
A6:

The program is broken.  It probably says "extern int errno" somewhere,
instead of including <errno.h>.  Errno in recent glibc versions is a macro,
which calls the function __errno_location; when glibc is built with
thread-local storage enabled, there is no extern int variable named errno. 
In addition, "extern int errno" is not thread-safe.

NOTE: Currently this error message is suppressed, for the benefit of some
truly buggy programs which redirect stderr into something important, like a
network socket.

Q7: I get this error when I compile an static linked application that's
compiled with glibc 2.2 or before:
	gcc -o foo.o libbar.a
	libbar.a(obj.o): In function `func(char *)':
	: undefined reference to `__ctype_toupper'

A7: 
During glibc 2.3.x development, some symbols (__ctype_b, __ctype_toupper,
__ctype_tolower) are changed to hidden attributes.  This means old static
linked applications/libraries built with glibc 2.2.x cannot be linked on glibc
2.3.x systems any more.

But it made a lot of user applications unusable, we applied a workaround patch
for glibc in Sarge.  Therefore your applications worked OK, and you didn't
need to consider about this problem.  However, most other distros already
dropped such local modification.  For that reason, we decided to drop
supporting such old static linked applications/libraries from Etch, you need
to recompile them.

If you want to keep this workaround that was applied in Sarge for the present,
please recompile Debian glibc package with adding "glibc23-ctype-compat" line
at the end of debian/patches/00list, and install it on your local machine.
Note that we don't support this patch nowadays, please use it at your own
risk.

${this.title}

Code Editor : libc.README.Debian