Re: fix the locking issue

[Gary V. Vaughan]

Hallo Ralf,

Ralf Wildenhues wrote:
> It is just intricate.  I'm don't mind a merge after 2.0, but if you deem
> it ok, I'd put it in CVS HEAD now.

Well, locks are just plain broken right now... and surely need to be
integrated more carefully with automake/autoconf in due course... but,
I trust your testing has already proven that this patch improves our
current situation somewhat, so I think it is safe to merge now.  Note
that I haven't performed any testing of my own on this patch (which I
had intended to do before I commented, and is how it got lost in my
mail archive).

> Notes:
> - The creation of the .libs/LoCk_SrC file may cause spurious errors on
>   w32 systems, thus the drop of stderr.
> - We cannot remove the .libs/LoCk_SrC file in compile mode: that could
>   defeat another libtool process concurrently running.  For the same
>   reason, it does not make sense to put the object file name in its
>   _name_.
> - Not creating the bugger in dry mode is necessary for mdemo-dryrun to
>   succeed.
> - Testing for its existence in clean mode before removing is a hack,
>   and won't save us in case the user is strange enough to do a parallel
>   clean with `rm' as opposed to `rm -f'.  The fact that it is removed on
>   the command line of the first object may seem a bit strange, however I
>   could not see a good reason to add more special code for this.
> - If the user actually passes a non-existing object file `foo.lo' as the
>   first one for this directory, then the `LoCk_SrC' file will not be
>   removed.
> - Surely it breaks for a 'libtool --mode=clean' concurrently with a
>   'libtool --mode=compile'.  Some sanity has to be expected from the user.
> - If any program has name `LoCk_SrC' and needs to be relinked upon
>   execution, things break horribly.

Please try to work these items in as comments at appropriate places in
the code.  Where impractical, adding them to the ChangeLog entry is okay.

> Unfixed issue (which I don't intend to attack now):
> 
> - need_locks is not tagged ATM.  It should not be (compiler_c_o already
>   is), but tests for later tags should not be able to set it to NO, if
>   earlier ones set it to something else.
> 
> - putting the object file name in the _contents_ of the lock file is
>   wrong, too, but AFAICS harmless, so it will be fixed later.

These too :-)

>       * libltdl/config/ltmain.m4sh (func_mode_compile): When locking
>       is necessary, hard-link against `.libs/lock_src' instead of
>       `$progpath'.
>       (func_mode_uninstall): In clean mode, remove `LoCk_SrC' if
>       present, along with the first object we remove.
>       Fixes potential hang reported by Marcin Siennicki and others.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature