[FAQ PATCH] Re: Latest Glibc from CVS has segmentation problems.

[Nix <nix at esperi dot org dot uk>]

On Sun, 07 Mar 2004, Ulrich Drepper spake:
> You do not really run make install to overwrite the files in a life
> system, do you?  Why should this work?

Er, it always has before, for every GNU package in my experience,
including glibc. Furthermore, it still does.

I've always been quite impressed by the degree of conformance to the GNU
Coding Standards that getting this to work for glibc implied. I'm aware
of the edge cases involving nasty ABI changes biting at the wrong
moment, but a few statically linked tools will fix that, so that the
installation can proceed from the installation of the first .so to the
installation of ld-linux.so.2 entirely without the assistance of the
dynamic linker.

Using distribution packaging tools strikes me as potentially dangerous,
although the danger is less than for a `make install'; in my experience,
these don't make any special effort to avoid fork()/exec(), and all you
need is one fork()/exec() in the wrong place and *boom*. Perhaps a tiny
special-purpose perl script to move all the core .so's and dynamic
linker into place at once is what's needed; we can be sure that *that*
won't fork()/exec() in the middle of copying. I'll whip something up.


I'm sure I'm preaching to the choir, but what's really dicing with death
is if you screw up the building of glibc and don't do a test install
first: this is, alas, increasingly common, not least with systems like
gentoo triggering builds and live installs of glibc without doing so
much as a `make check' first. In that situation just about all you know
is that the newly built ld.so doesn't crash for an rpcgen built against
the newly built glibc!  :)


In a desperate attempt to get something useful out of this blasted
flamewar, and in the interest of making life easier for non-ELF-lords,
here's a couple of FAQ entries describing some problems I encountered
building glibc.

Edit at will :)

Index: FAQ.in
===================================================================
RCS file: /cvs/glibc/libc/FAQ.in,v
retrieving revision 1.134
diff -u -r1.134 FAQ.in
--- FAQ.in	9 Dec 2002 22:57:03 -0000	1.134
+++ FAQ.in	17 Mar 2004 00:11:18 -0000
@@ -374,6 +372,108 @@
 
 {SM} You want to use at least gcc 3.2 (together with the right versions
 of all the other tools, of course).
+
+??	I get a segmentation fault running `rpcgen' during compilation.
+
+{NA} This failure usually indicates that something is wrong with the dynamic
+linker that's just been built: this is the first time it is run during the build
+process. A very wide range of things may be wrong, and it can be difficult to
+determine what those things are without knowledge of the minutiae of ELF
+relocation handling. The most frequent cause of this failure seems to be
+toolchain bugs, particularly in the linker.
+
+If your toolchain is working, another fairly frequent (and easily fixable) cause
+of this failure on some architectures is that glibc needs to know your real
+architecture name, so that it can incorporate correct code from the sysdeps
+tree. config.guess does not always guess correctly (for instance, on sparcv9
+systems in 32-bit mode, it guesses that you have a sparcv7).
+
+Keep an eye on the first few lines printed by `configure' and see if things seem
+to be being built for a different subarchitecture than they should be.
+If so, try providing the --build parameter to configure, to guide it in the
+right direction.
+
+(e.g., on UltraSPARC in 32-bit mode, --build=sparcv9-unknown-linux-gnu is
+necessary.)
+
+??sparc64	I get errors compiling setgroups.c.
+
+{NA} This tends to indicate that you haven't massaged your kernel header files
+correctly. On mixed-universe systems (like SPARC64 with a 32-bit userspace), you
+have to arrange that you see the correct kernel headers both when compiling
+64-bit code (when you should see the sparc64 kernel headers) and when compiling
+32-bit code (when you should see the sparc32 headers).
+
+A script something like this will set up the header files correctly.
+
+-----------------------------------------------------------------------
+#!/bin/sh -e
+
+if [ -n "$1" ]; then
+	if [ ! -d "$1" ]; then
+		echo "$1" does not exist, or is not a directory
+		exit 1
+	fi
+	cd $1
+else
+	cd /usr/include
+fi
+
+if [ ! -d asm-sparc -o ! -d asm-sparc64 ] ; then
+	echo E: asm-sparc and asm-sparc64 must exist, or you will have problems
+	exit 1
+fi
+
+rm -rf asm
+mkdir asm
+
+for h in `( ls asm-sparc; ls asm-sparc64 ) | grep '\.h$' | sort -u`; do
+	name=`echo $h | tr a-z. A-Z_`
+	# common header
+	cat > asm/$h << EOF
+/* All asm/ files are generated and point to the corresponding
+ * file in asm-sparc or asm-sparc64.
+ */
+
+#ifndef __SPARCSTUB__${name}__
+#define __SPARCSTUB__${name}__
+
+EOF
+
+	# common for sparc and sparc64
+	if [ -f asm-sparc/$h -a -f asm-sparc64/$h ]; then
+		cat >> asm/$h <<EOF
+#ifdef __arch64__
+#include <asm-sparc64/$h>
+#else
+#include <asm-sparc/$h>
+#endif
+EOF
+
+	# sparc only
+	elif [ -f asm-sparc/$h ]; then
+		cat >> asm/$h <<EOF
+#ifndef __arch64__
+#include <asm-sparc/$h>
+#endif
+EOF
+	# sparc64 only
+	else
+		cat >> asm/$h <<EOF
+#ifdef __arch64__
+#include <asm-sparc64/$h>
+#endif
+EOF
+	fi
+
+	# common footer
+	cat >> asm/$h <<EOF
+
+#endif /* !__SPARCSTUB__${name}__ */
+EOF
+
+done
+-----------------------------------------------------------------------
 
 ? Installation and configuration issues
 
-- 
RMKQLEEKVYELLSKVACLEYEVARLKKVGE
  -- ligate me, I want to live