summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2008-11-26 00:22:28 +0100
committerThomas Schwinge <tschwinge@gnu.org>2008-11-26 00:22:28 +0100
commit0e532fa981a9b1ad8e1165dfe4375fbb9fca95e3 (patch)
tree2c8d5bcd979d4d384d1fcfb4b687ecb1b0c05e2b /hurd
parent09c5e12d0801437e75c7af45c9a743e2f764b276 (diff)
Incorporate <http://sourceware.org/ml/libc-alpha/2008-11/msg00031.html> and further improvements.
Diffstat (limited to 'hurd')
-rw-r--r--hurd/debugging/glibc.mdwn46
1 files changed, 32 insertions, 14 deletions
diff --git a/hurd/debugging/glibc.mdwn b/hurd/debugging/glibc.mdwn
index f0fe8b61..54a3446c 100644
--- a/hurd/debugging/glibc.mdwn
+++ b/hurd/debugging/glibc.mdwn
@@ -13,11 +13,11 @@ glibc have been done.
---
-First step is having the build a glibc complete. This is actually more
-difficult than one might expect, as it involves (towards the end of the build
-process; unless you are cross-building, of course), that the newly created
-libraries and loader actually work: they're used to run the `rpcgen`
-program. If that step doesn't succeed, it'll look similar to this:
+First step is having the build of glibc succeed. This is actually more
+difficult than one might expect as it involves (towards the end of the build
+process -- unless you are [[building/cross-compiling]], of course -- that the
+newly created libraries and loader actually work: they'll be used to run the
+`rpcgen` program. If that step doesn't succeed, it'll look similar to this:
[...]
CPP='gcc -E -x c-header' [...]/build/elf/ld.so.1 --library-path [...] [...]/build/sunrpc/rpcgen [...]
@@ -25,8 +25,8 @@ program. If that step doesn't succeed, it'll look similar to this:
---
-If building glibc succeeds, the next thing to try is running the test suite, or
-parts of it.
+Unless [[building/cross-compiling]], the next thing you'll probably want to do
+is running the test suite, or parts of it.
Here is a list of known failures:
@@ -34,10 +34,28 @@ Here is a list of known failures:
---
-Make sure static linking is working OK at all. The `elf/sln` program (a
-stripped-down `ln` that is statically linked) in the glibc build ought to test
-that. Also, static linking under various conditions will already have been
-tested when running the test suite, especially in `elf/` and `dlfcn/`.
+If you've been doing simple changes to glibc functions that end up in
+`libc.so`, you may test them like this (like for a `strerror_l` implementation
+in this case):
+
+ $ LD_PRELOAD=./libc.so ./ld.so ./a.out 10 1073741928 de_DE.utf8
+ 1073741928 (0x40000068): Computer bought the farm
+ 1073741928 (0x40000068): Der Computer hat den Bauernhof erworben
+
+You usually will only have luck using the new `libc.so` (from
+`[glibc-build]/libc.so`) in combination together with the new `ld.so` (from
+`[glibc-build]/elf/ld.so`):
+
+ $ LD_PRELOAD=./libc.so ./a.out 10 1073741928 de_DE.utf8
+ Killed
+ $ LD_PRELOAD=./libc.so /lib/ld.so ./a.out 10 1073741928 de_DE.utf8
+ Killed
+
+Make sure static linking is working OK at all. Running the
+`[glibc-build]/elf/sln` program (a stripped-down `ln` that is statically
+linked) ought to test that. Also, static linking under various conditions will
+already have been tested when running the test suite, especially in `elf/` and
+`dlfcn/`.
Make sure static linking with cthreads is working. If you can get an
`ext2fs.static` compiled and linked against the new glibc, that is good.
@@ -51,8 +69,8 @@ Then debug its startup as a normal program on your working hurd.
Then try its full server startup.
- $ settrans -ca node [...]/ext2fs.static <BACKEND>
- $ cd node/
+ $ settrans -ca node [...]/ext2fs.static BACKING_STORE
+ $ ls -l node/
[...]
Make sure dynamic linking for servers is working. If you haven't broken the
@@ -61,7 +79,7 @@ glibc's `testrun.sh` does it.
[TODO]: Is this the correct way to do that?
- $ settrans -ca node [glibc]/build/testrun.sh /hurd/ext2fs <BACKEND>
+ $ settrans -ca node [glibc]/build/testrun.sh /hurd/ext2fs BACKING_STORE
$ cd node/
[...]