pine producing gratuitous folder locks

["David C. Winters" <winters@giri.intro.cs.cmu.edu>]

Today, I started getting running into a problem with Pine 3.94--it began
telling me that every folder I tried accessing was locked.  This persisted
even after I rebooted the machine, so I upgraded to Pine 3.95q out of the 
3.95L-7 .deb package.  This resulted in the same thing--if I try to open a
folder, it's locked.  After looking through /usr/doc/pine/tech-notes, I
checked for <whatever>.lock files corresponding to the various folders, as
well as a general lockfile in either /var/lock or /tmp without finding
anything promising.  Has anyone else run into this with this package?

D.

David winters+@cs.cmu.edu	If the Force with Yoda is so strong, construct
Office: 3503 WeH, x86720	a sentence with in the proper order the words
MTFBWY				then why can't he?

Received: (qmail 30332 invoked by uid 888); 7 Mar 1997 18:29:03 -0000
Delivered-To: debian-lists--devel@master.debian.org
Received: (qmail 30330 invoked by uid 888); 7 Mar 1997 18:29:03 -0000
Delivered-To: debian-devel@debian.org
Received: (qmail 30326 invoked from network); 7 Mar 1997 18:29:02 -0000
Received: from nhv-ct1-21.ix.netcom.com (HELO sauron.fashion-tech.com) (mail@205.184.152.53)
  by master.debian.org with SMTP; 7 Mar 1997 18:29:01 -0000
Received: from klee by sauron.fashion-tech.com with local (Exim 1.60 #1)
	id 0w34Fi-0001AT-00 (Debian); Fri, 7 Mar 1997 13:20:02 -0500
From: Klee Dienes <klee@mit.edu>
Reply-To: Klee Dienes <klee@mit.edu>
To: maintonly@bugs.debian.org, debian-devel@debian.org
Subject: debstd strips static libraries?
Message-Id: <E0w34Fi-0001AT-00@sauron.fashion-tech.com>
Sender: Klee Dienes <klee@sauron.fashion-tech.com>
Date: Fri, 7 Mar 1997 13:20:02 -0500


Package: debmake
Version: 3.2.2

I'm filing this as a bug against debmake, but it may in fact be just a
figment of my misunderstanding.  Consider it a request for information
as much as anything else.

Can anyone direct me to a decent reference on the ELF format as used
by Linux?  I have the Intel ELF specification (version 1.1 of October
1993), but it seems to be substantially different from the ELF used by
Linux.

Lines 401--411 of /usr/bin/debmake:

   	# Check for static libraries provided by the package
	X=`find $2/lib $2/usr/lib $2/usr/X11R6/lib -type f -name "lib*.a" 2>/dev/null`
	if [ "$X" != "" ]; then
		echo "-- Processing provided static libraries"
		for i in $X; do
			echo "Static Library $i"
			if ! expr "$i" : ".*_g\.a" >/dev/null; then
				strip $i
			fi
		done
	fi

So far as I can tell, this makes all static libraries processed by
debmake unusable, as they no longer contain the symbols needed to
allow linking.

I'd suggest changing line 408 to 'strip --strip-unneeded $i', but that
seems to remove necessary symbols for static linking as well (making
it useless for Linux, as all 'symbols necessary for relocation' are in
the .dynsym and .dynstr sections anyway).  

Probably both lines 388 and 408 of /usr/bin/debmake should be changed
to use '--strip-debug', as '--strip-debug' is the only thing that 
seems to leave enough information around for linking against the library.

I'm tempted to also file a bug against binutils for this same problem,
as '--strip-unneeded' is a pretty crappy option that makes a static
library unusable for linking.  Opinions?

Finally, as an aside, is it policy that all static libraries with
debugging information be named libxxx_g.a?  Or is this just a
convention used by debstd?

Thanks,
 - Klee