r3676 - in glibc-package/trunk/debian: . debhelper.in rules.d
Author: aurel32
Date: 2009-07-26 16:59:00 +0000 (Sun, 26 Jul 2009)
New Revision: 3676
Added:
glibc-package/trunk/debian/debhelper.in/libc.README.Debian
Removed:
glibc-package/trunk/debian/FAQ
Modified:
glibc-package/trunk/debian/rules.d/debhelper.mk
Log:
Install the FAQ directly as README.Debian
Deleted: glibc-package/trunk/debian/FAQ
===================================================================
--- glibc-package/trunk/debian/FAQ 2009-07-26 16:56:43 UTC (rev 3675)
+++ glibc-package/trunk/debian/FAQ 2009-07-26 16:59:00 UTC (rev 3676)
@@ -1,117 +0,0 @@
-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.
- ld.so: See /usr/share/doc/libc6/FAQ.gz.
-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.
Copied: glibc-package/trunk/debian/debhelper.in/libc.README.Debian (from rev 3665, glibc-package/trunk/debian/FAQ)
===================================================================
--- glibc-package/trunk/debian/debhelper.in/libc.README.Debian (rev 0)
+++ glibc-package/trunk/debian/debhelper.in/libc.README.Debian 2009-07-26 16:59:00 UTC (rev 3676)
@@ -0,0 +1,117 @@
+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.
+ ld.so: See /usr/share/doc/libc6/FAQ.gz.
+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.
Modified: glibc-package/trunk/debian/rules.d/debhelper.mk
===================================================================
--- glibc-package/trunk/debian/rules.d/debhelper.mk 2009-07-26 16:56:43 UTC (rev 3675)
+++ glibc-package/trunk/debian/rules.d/debhelper.mk 2009-07-26 16:59:00 UTC (rev 3676)
@@ -22,8 +22,6 @@
install --mode=0644 nptl/ChangeLog debian/$(curpass)/usr/share/doc/$(curpass)/ChangeLog.nptl
# dh_installmanpages thinks that .so is a language.
install --mode=0644 debian/local/manpages/ld.so.8 debian/$(curpass)/usr/share/man/man8/ld.so.8
-
- install --mode=0644 debian/FAQ debian/$(curpass)/usr/share/doc/$(curpass)/README.Debian
endef
# Should each of these have per-package options?
Reply to: