Re: Creating lock file for compilers that don't support -c -o

2003-08-26 Thread Robert Collins
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

Re: Creating lock file for compilers that don't support -c -o

2003-08-26 Thread Sascha Schumann
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

Re: Creating lock file for compilers that don't support -c -o

2003-08-26 Thread Albert Chin
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

Re: Creating lock file for compilers that don't support -c -o

2003-08-26 Thread Earnie Boyd
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

Re: Creating lock file for compilers that don't support -c -o

2003-08-26 Thread Bob Friesenhahn
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?

Re: Creating lock file for compilers that don't support -c -o

2003-08-26 Thread Bob Friesenhahn
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

Re: Creating lock file for compilers that don't support -c -o

2003-08-26 Thread Bob Friesenhahn
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:

Creating lock file for compilers that don't support -c -o

2003-08-25 Thread Albert Chin
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])

Re: Creating lock file for compilers that don't support -c -o

2003-08-25 Thread Paul Jarc
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

Re: Creating lock file for compilers that don't support -c -o

2003-08-25 Thread Bob Friesenhahn
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

Re: Creating lock file for compilers that don't support -c -o

2003-08-25 Thread Paul Jarc
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.