arla 0.20: getcwd & XFS panics

[Brandon S. Allbery KF8NH]

In message <E0ztLNz-0000Ys-00 at chinook.stanford.edu>, Max writes:
+-----
| I just compiled Arla 0.20 and noticed some major problems.  The first
| mistake was copying getcwd.so to /lib.  I did this with all the other
| versions with no major problems.  My /etc/ld.so.preload has been
| modified appropriately.  As soon as I overwrote the old getcwd.so, the
| system started responding to EVERY command with "Segmentation fault".
+--->8

You didn't pay attention to the instructions, then.  Overwriting a shared 
library that's in use is fatal in Linux; the install instructions in the 
announcement specifically stated that you need to rename the existing 
getcwd.so, then copy the new one in, so the running copy isn't overwritten.

| log in and remove getcwd.so from ld.so.preload.  Until I did that, I
| couldn't start X (it complained about a missing __getcwd symbol).
+--->8

Is your X server (or wrapper) linked against glibc2/libc6 or libc5?  If 
glibc2, what version?  In glibc-2.0.x, __getcwd is the real getcwd() call; 
getcwd is a weak symbol, so that it can be redefined in exactly the way the 
replacement getcwd.so does while leaving the original available.  Or should 
be.  It's working here (Red Hat 5.2, glibc-2.0.7) but I have no Debian 
systems to compare against.

What does "nm --defined-only --dynamic /lib/libc.so.6 | grep getcwd" print?  
It should be something like:

3 at rushlight:1002 B$ nm --defined-only --dynamic /lib/libc.so.6 | grep getcwd
00069230 T __getcwd
00069230 W getcwd

(If the program that's failing is linked against libc5, all bets are off.)

-- 
brandon s. allbery	[os/2][linux][solaris][japh]	 allbery at kf8nh.apk.net
system administrator	     [WAY too many hats]	   allbery at ece.cmu.edu
carnegie mellon / electrical and computer engineering			 KF8NH
     We are Linux. Resistance is an indication that you missed the point.