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.
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 no
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, Albert Chin wrote:
> 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?
Creat
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])
On Sun, Aug 24, 2003 at 02:32:37AM -0400, Greg Hudson wrote:
> > When libtool builds these convenience libraries, it adds the static
> > libstdc++ library (by extracting the contents of libstdc++, then
> > adding it to the convenience library)
>
> I'm seeing the same thing on Solaris 9, with a gcc
