[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
libtool's locking is wrong
From: |
Pavel Cahyna |
Subject: |
libtool's locking is wrong |
Date: |
Wed, 26 Feb 2003 17:00:43 +0100 |
User-agent: |
Mutt/1.3.28i |
Hello,
libtool contains this:
# Lock this critical section if it is needed
# We use this script file to make the link, it avoids creating a new file
if test "$need_locks" = yes; then
until $run ln "$0" "$lockfile" 2>/dev/null; do
$show "Waiting for $lockfile to be removed"
sleep 2
done
The ln command fails if the libtool script itself
and the working directory are on different filesystems.
This can be seen only if configure determines that cc doesn't support -c
-o file:
checking if cc supports -c -o file.o... no
This can't happen with gcc. It happened on IRIX, using SGI's MIPSpro
compiler, while compiling gettext-lib from NetBSD's packages collection.
The output was:
...
===> Building for gettext-lib-0.11.5
/bin/sh ../libtool --mode=compile cc -c
-DLOCALEDIR=\"/usr/pkg/share/locale\"
-DLOCALE_ALIAS_PATH=\"/usr/pkg/share/locale\" -DLIBDIR=\"/usr/pkg/lib\"
-DIN_LIBINTL -DHAVE_CONFIG_H -I.. -I. -I../intl -I/usr/pkg/include -O2
-I/usr/pkg/include intl-compat.c
Waiting for intl-compat.o.lock to be removed
Waiting for intl-compat.o.lock to be removed
Waiting for intl-compat.o.lock to be removed
Waiting for intl-compat.o.lock to be removed
.... ad infinitum.
Libtool's version:
ltmain.sh (GNU libtool) 1.4a (1.641.2.255 2001/05/22 10:39:30)
This is probably also the cause of recent bugreport under subject
"Waiting for a.o.lock to be removed" (from 24 Feb 2003).
Bye Pavel
- libtool's locking is wrong,
Pavel Cahyna <=