away from my mail

2003-08-26 Thread via the vacation program
I have recently moved to Vanderbilt University and may not be able to reply to your email for a while. If you have any questions regarding ACE or TAO please send them to the ACE+TAO mailing list or comp.soft-sys.ace newsgroup, as described in http://www.cs.wustl.edu/~schmidt/ACE-mail.html. If

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

running libtool from emacs gud mode

2003-08-26 Thread Justin Randall
I know this was asked once before, but I couldn't find any answers to the question. Sorry if this is a FAQ. I can usually run gdb from emacs using M-x gdb Run gdb (like this): gdb target Of course, to run gdb on a libtool output file that has not yet been installed, from the command line I

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: running libtool from emacs gud mode

2003-08-26 Thread Justin Randall
applying this to gud.el, deleting gud.elc should solve it for anyone that's interested. 310,311c310 (cons -cd (cons (expand-file-name default-directory) (cons -fullname args --- (append args (list -cd (expand-file-name default-directory) -fullname ))) I've tested

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: