bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O


From: Jeff Squyres
Subject: Re: Bug in LT 1.5 AC_LIBTOOL_PROG_CC_C_O
Date: Tue, 6 Jan 2004 21:12:48 -0500 (EST)

On Sun, 4 Jan 2004, Bob Friesenhahn wrote:

> > I think it is correct to test for this condition and to set
> > enable_libtool_lock if it occurs.  I do agree that
> > AC_LIBTOOL_PROG_CC_C_O is the wrong place to do that.

I think we all agree on this point, especially since there is at least
one case that generates a false positive (quite a common case in the
high-performance computing arena; lots of people use the Intel
compiler for its great performance).

So let's ditch that chmod in the AC_LIBTOOL_PROG_CC_C_O!  ;-)

> But there is nothing technically wrong with compilers creating temporary
> files in the current directory!  This may even be more reliable for
> machines with small /tmp directories.
>
> I believe that libtool is incorrect to assume that locking must be used
> if the compiler places its temporary files in the current directory.
> There may be a few compilers in the world which are not smart enough to
> create non-conflicting temporary files, but these are surely in the
> minority.  It would be wiser to assume that compilers work correctly,
> and positively identify the few that don't.  People with broken tools
> should not attempt parallel builds anyway.

So the issue is: does the compiler reliably support parallel builds in a
single directory?  Some points (in no particular order):

- Testing for this behavior should probably be a new, standalone
  macro.

- Given that Bob makes excellent points about generated temporary
  files in the cwd, how exactly would one test for whether a compiler
  exhibits this "bad" kind of behavior?

- Does libtool really care about this?  i.e., where exactly should
  this be reported to the user?

  - Never: the M4 test figures it out and automatically locks or
    doesn't lock (which is the current intended behavior)
  - During a parallel build: i.e., configure doesn't try to figure
    anything out, and if the user does a parallel build with a
    badly-performing compiler, the build will just fail (probably
    spectacularly :-)

  The first option is obviously more desirable from an end-user
  perspective; the second option is clearly easier to write and
  support (especially if it really is a very small minority of
  compilers that exhibit this bad behavior -- it's the "doc, it hurts
  when I go like this"/"then don't do that" kind of story).

My $0.02: users who have compilers that don't support parallel builds
already know it, and won't try it.  It's not worth additional code in
libtool that could be difficult to write and maintain.

-- 
{+} Jeff Squyres
{+} address@hidden
{+} http://www.lam-mpi.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]