[434] in arla-drinkers
Re: arla 0.20: getcwd & XFS panics
daemon@ATHENA.MIT.EDU (Brandon S. Allbery KF8NH)
Fri Dec 25 19:17:59 1998
From owner-arla-drinkers@stacken.kth.se Sat Dec 26 00:17:59 1998
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 11279 invoked from network); 26 Dec 1998 00:17:58 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 26 Dec 1998 00:17:58 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id BAA04397
for arla-drinkers-list; Sat, 26 Dec 1998 01:13:32 +0100 (MET)
Received: from hilfy.ece.cmu.edu (root@HILFY.ECE.CMU.EDU [128.2.253.106])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id BAA04393;
Sat, 26 Dec 1998 01:13:28 +0100 (MET)
Received: from speaker.kf8nh.apk.net (root@ANNEX-2.SLIP.ECE.CMU.EDU [128.2.236.2])
by hilfy.ece.cmu.edu (8.8.8/8.8.8) with ESMTP id TAA16204;
Fri, 25 Dec 1998 19:13:24 -0500 (EST)
Received: from rushlight.kf8nh.apk.net (allbery@rushlight.kf8nh.apk.net [10.9.204.1])
by speaker.kf8nh.apk.net (8.8.7/8.8.7) with ESMTP id TAA14149;
Fri, 25 Dec 1998 19:13:24 -0500
Received: (from allbery@localhost)
by rushlight.kf8nh.apk.net (8.8.7/8.8.7) id TAA00864;
Fri, 25 Dec 1998 19:13:20 -0500
Message-Id: <199812260013.TAA00864@rushlight.kf8nh.apk.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: assar@stacken.kth.se
cc: Max <maxk@chinook.stanford.edu>, arla-drinkers@stacken.kth.se
Subject: Re: arla 0.20: getcwd & XFS panics
In-reply-to: Your message of "26 Dec 1998 00:32:16 +0100."
<5lbtkrer27.fsf@assaris.sics.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 25 Dec 1998 19:13:20 -0500
From: "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
In message <5lbtkrer27.fsf@assaris.sics.se>, assar@stacken.kth.se writes:
+-----
| Max <maxk@chinook.stanford.edu> writes:
| > Until I did that, I couldn't start X (it complained about a missing
| > __getcwd symbol).
|
| According to my understanding, this means there's some program that's
| linked against libc5 (which doesn't have a __getcwd).
+--->8
Yes, very likely. Although I thought Debian was fully libc6.
| What has changed is that getcwd.so tries to fallback on calling
| __getcwd if it doesn't find a getcwd system call. This fails with
| libc5 becaus it doesn't have a __getcwd symbol. I've tried to make a
| solution that works with libc5 but failed.
+--->8
Obtain the libc5 source, pull out getcwd.c, then modify it so getcwd is
declared as ___getcwd and __getcwd is a weak symbol (similar to libc6).
int
___getcwd (/* ... */)
{
/* ... */
}
int __getcwd (/* ... */) __attribute__ (weak, alias ("___getcwd"));
Compile this against libc5 to produce a shared object, which is then added
to /etc/ld.so.preload. Now libc6 programs will use the non-weak __getcwd in
/lib/libc.so.6, while libc5 programs will follow the weak symbol to
___getcwd because there is no non-weak __getcwd.
--
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.
