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

Fri May 6 14:47:52 EDT 2016

Andrew,

Pretty sure you can write to a running processes file (as I've done it in
the past, though it may have been solaris rather than linux).

How long is the full link(s) taking for you?
Are you doing static linking? or shared?

-Bill

On Fri, May 6, 2016 at 2:27 PM, Andrew C. Morrow <andrew.c.morrow at gmail.com>
wrote:

>
> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/97b11e21/attachment-0001.html>