[Scons-users] Make all Program and SharedLibrary targets implicitly Precious?

[Andrew C. Morrow]

It is actually a little worse than I thought. On linux at least, it seem to
prevent you from writing to a running executable:

$ cp /bin/cat ./catty
$ ./catty -

In another shell:

$ cat /dev/null > catty
-bash: catty: Text file busy

So, if you mark executables as Precious, your build might fail if the
executable is running when you build.

I haven't checked if that is true of shared libraries as well.


On Sat, Apr 30, 2016 at 5:30 PM, Andrew C. Morrow <andrew.c.morrow at gmail.com
> wrote:

>
>
> On Sat, Apr 30, 2016 at 4:38 PM, Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>> Andrew,
>>
>> How about a pre-action to mv the existing file to another name, and then
>> copy it to original name, then incremental link the copy?
>>
>
> That should work too, as long as there is a way to make a forced copy that
> isn't actually a hard link.
>
>
>
>> That should resolve the crashing bit.
>>
>> lsof filename won't help if the files being used on another system, but
>> would if on current system. (to see if in use)
>>
>
> Trying to see if it is in use seems racy. I think it is probably better to
> move it aside as you suggest above. In either approach though there is
> still a copy. I guess the real question is how much faster incremental
> linking can be.
>
> However, I think lg.gold's incremental support may not be quite ready to
> go:
>
> - Binaries linked in incremental mode seem to segfault before main
> - An actual incremental relink causes ld.gold to crash
>
> It still might be useful though to have support for this for MSVC
> /INCREMENTAL and /DEBUG:FASTLINK support.
>
>
>
>>
>>
>> -Bill
>>
>> On Sat, Apr 30, 2016 at 3:47 PM, Andrew C. Morrow <
>> andrew.c.morrow at gmail.com> wrote:
>>
>>>
>>> Definitely a possibility. MongoDB probes for compiler support for
>>> ld.gold and prefers it by default:
>>>
>>> https://github.com/mongodb/mongo/blob/master/SConstruct#L2164-L2167
>>>
>>> The downside to using incremental linking and making dynamic targets
>>> Precious is that by overwriting the binaries you end up crashing running
>>> programs that have them mapped. That happens often enough during developer
>>> workflow that it is unfortunate.
>>>
>>> So, it definitely should be opt-in behavior, and a Tool sounds right for
>>> that.
>>>
>>> I also wonder whether such a Tool might be able to make intelligent use
>>> of gold's --incremental-base file to avoid the above problem. If you first
>>> copied the dynamic target aside under a different name, then unlinked the
>>> original, then used --incremental-base pointing to the moved-aside file,
>>> perhaps you could avoid crashing programs that have the target mapped. I'm
>>> not sure though if the cost of the file copy would eat up most of the gains
>>> from incremental linking.
>>>
>>> That sounds complex enough to also warrant a separate Tool.
>>>
>>>
>>> On Fri, Apr 29, 2016 at 1:52 PM, Bill Deegan <bill at baddogconsulting.com>
>>> wrote:
>>>
>>>> Andrew,
>>>>
>>>> Might make sense to make a gold linker tool?
>>>>
>>>> -Bill
>>>>
>>>> On Fri, Apr 29, 2016 at 9:47 AM, Andrew C. Morrow <
>>>> andrew.c.morrow at gmail.com> wrote:
>>>>
>>>>>
>>>>> Thanks Bill -
>>>>>
>>>>> I think that sounds promising, I'll give it a look. If I get it
>>>>> working well I'll ping the list back and describe my findings.
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>>
>>>>> On Fri, Apr 29, 2016 at 12:10 PM, Bill Deegan <
>>>>> bill at baddogconsulting.com> wrote:
>>>>>
>>>>>> Andrew,
>>>>>>
>>>>>> Likely you want to stick this logic in the emitter for building
>>>>>> libraries and programs.
>>>>>> SCons/Tool/link.py  shlib_emitter() is the current logic.
>>>>>> The environment tracks this in:
>>>>>> env['SHLIBEMITTER'] which is a list.
>>>>>> So if you append to SHLIBEMITTER and mark the relevant nodes
>>>>>> Precious()
>>>>>> env['PROGEMITTER'] is the emitter for programs. Looks like it's only
>>>>>> defined for mslink and qt, so you can defined one on non qt/mslink freely
>>>>>> and do the same.
>>>>>>
>>>>>> Hope that helps
>>>>>> -Bill
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 29, 2016 at 8:52 AM, William Blevins <
>>>>>> wblevins001 at gmail.com> wrote:
>>>>>>
>>>>>>> Andrew,
>>>>>>>
>>>>>>> I expect that you could make a Pseudo-Builder that wraps Program and
>>>>>>> Library calls, and replace the top-level calls with your wrappers.
>>>>>>>
>>>>>>> I think you can replace them like env['BUILDERS']['xxxxxx'] =
>>>>>>> Wrapper or env.AddMethod but I haven't tested this explicitly.
>>>>>>>
>>>>>>> https://bitbucket.org/scons/scons/wiki/ToolsForFools
>>>>>>>
>>>>>>> V/R,
>>>>>>> William
>>>>>>>
>>>>>>> On Fri, Apr 29, 2016 at 4:21 PM, Andrew C. Morrow <
>>>>>>> andrew.c.morrow at gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hi -
>>>>>>>>
>>>>>>>> Is there a simple way to do this? I'd like to use ld.gold's
>>>>>>>> incremental linking, but I don't want to need to add .Precious to every
>>>>>>>> executable and library in my project.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Scons-users mailing list
>>>>>>>> Scons-users at scons.org
>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Scons-users mailing list
>>>>>>> Scons-users at scons.org
>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-users at scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-users at scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-users at scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-users at scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160506/f3c69c12/attachment.html>