On Tue, 2003-08-26 at 12:58, Albert Chin wrote:
Why not use $srcfile and $srcfile.lock as the lock file? So, rather
than:
They may be on different fs's.
Rob
--
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
___
Libtool
I'd rather see a link to the POSIX standard defining link as atomic.
IEEE Std 1003.1-2003
http://www.opengroup.org/onlinepubs/007904975/functions/link.html
The link() function shall atomically create a new link for
the existing file and the link count of the file shall be
On Tue, Aug 26, 2003 at 01:49:10PM +1000, Robert Collins wrote:
On Tue, 2003-08-26 at 12:58, Albert Chin wrote:
Why not use $srcfile and $srcfile.lock as the lock file? So, rather
than:
They may be on different fs's.
How is that possible? If we use $srcfile.lock as the lock file it is
Paul Jarc wrote:
Bob Friesenhahn [EMAIL PROTECTED] wrote:
Creating a symbolic link requires testing for an existing file, and
then (if the file does not exist) creating a new file, and a
directory entry to reference it. This requires multiple network
transactions with an opportunity for
On Tue, 26 Aug 2003, Albert Chin wrote:
On Tue, Aug 26, 2003 at 01:49:10PM +1000, Robert Collins wrote:
On Tue, 2003-08-26 at 12:58, Albert Chin wrote:
Why not use $srcfile and $srcfile.lock as the lock file? So, rather
than:
They may be on different fs's.
How is that possible?
On Tue, 26 Aug 2003, Robert Collins wrote:
On Tue, 2003-08-26 at 12:58, Albert Chin wrote:
Why not use $srcfile and $srcfile.lock as the lock file? So, rather
than:
They may be on different fs's.
Right. It is possible for libtool, the source files, and the object
files, to reside on
On Tue, 26 Aug 2003, Albert Chin wrote:
On Tue, Aug 26, 2003 at 10:56:47AM -0500, Bob Friesenhahn wrote:
On Tue, 26 Aug 2003, Robert Collins wrote:
On Tue, 2003-08-26 at 12:58, Albert Chin wrote:
Why not use $srcfile and $srcfile.lock as the lock file? So, rather
than:
If a compiler doesn't support -c -o, libtool creates a lock file by
hard linking the libtool binary with the lock file. This is a problem
if the libtool binary is on a different file system than the lock
file. Why don't we use a symbolic link?
--
albert chin ([EMAIL PROTECTED])
Bob Friesenhahn [EMAIL PROTECTED] wrote:
Creating a hard link is an atomic operation whereas a symbolic link is
not
How so?
paul
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Mon, 25 Aug 2003, Paul Jarc wrote:
Bob Friesenhahn [EMAIL PROTECTED] wrote:
Creating a hard link is an atomic operation whereas a symbolic link is
not
How so?
It has to do with the complexity of the operation, particularly if a
network is involved. Creating a hard link does not create
Bob Friesenhahn [EMAIL PROTECTED] wrote:
Creating a symbolic link requires testing for an existing file, and
then (if the file does not exist) creating a new file, and a
directory entry to reference it. This requires multiple network
transactions with an opportunity for race-conditions.
11 matches
Mail list logo