[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fix the locking issue
From: |
Gary V. Vaughan |
Subject: |
Re: fix the locking issue |
Date: |
Tue, 21 Feb 2006 13:07:11 +0000 |
User-agent: |
Thunderbird 1.5 (X11/20051201) |
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