[Scons-users] SHLIBVERSION questions
William Blevins
wblevins001 at gmail.com
Sun Jun 14 14:42:50 EDT 2015
So it turns out this is indirectly caused by
https://bitbucket.org/scons/scons/pull-request/86/fix-http-sconstigrisorg-issues/diff
# Fix http://scons.tigris.org/issues/show_bug.cgi?id=2903 :
> # Ensure we still depend on SCons.Defaults.ShLinkAction command line which
> is $SHLINKCOM.
> # This was tricky because we don't want changing LIBPATH to cause a
> rebuild, but
> # changing other link args should. LIBPATH has $( ... $) around it but
> until this
> # fix, when the varlist was added to the build sig those ignored parts
> weren't getting
> # ignored.
> ShLibAction = SCons.Action.Action(VersionedSharedLibrary, None,
> varlist=['SHLINKCOM'])
>
I think the intention of the fix makes sense but see last email.
V/R,
William
On Sun, Jun 14, 2015 at 2:32 PM, William Blevins <wblevins001 at gmail.com>
wrote:
> Order of events:
>
> 1. make_ready called on node libcc.so.0.1.0, action = gcc -o
> libcc.so.0.1.0 -shared cc.os
> 1. At this point, node libcc.so.0.1.0 bact differs from
> .sconsign.dblite (IE. the correct value)
> 2. Node marked as requiring update
> 2. Tool/__init__.py:VersionedSharedLibrary executes and modifies
> the ShLinkAction
> 1. The action is now correct and match the .sconsign.dblite value,
> action = gcc -o libcc.so.0.1.0 -shared -Wl,-Bsymbolic
> -Wl,-soname=libcc.so.0 cc.os
> 3. .sconsign.dblite written with action from step 2
>
> I hope this marks sense. Not immediately sure how to resolve.
>
> V/R,
>
> William
>
> On Sun, Jun 14, 2015 at 2:01 PM, William Blevins <wblevins001 at gmail.com>
> wrote:
>
>> I think my original assumption was silly. More like the command is
>> changing after the initial action is created...
>>
>> V/R,
>> William
>>
>> On Sun, Jun 14, 2015 at 1:23 PM, William Blevins <wblevins001 at gmail.com>
>> wrote:
>>
>>> Here is some additional information for anyone with indepth knowledge of
>>> the VersionedSharedLibrary tool.
>>>
>>> Sample SConstruct: SharedLibrary( 'cc', 'cc.c', SHLIBVERSION = '0.1.0' )
>>>
>>> bactsig is computed as md5( executor.get_contents() ) and the executor
>>> contents differ between lookups at byte 2828 line 162.
>>>
>>> Pass 1: "S),(N.,N.,N.),()gcc -o libcc.so.0.1.0 -shared cc.osgcc -o
>>> libcc.so.0.1.0 -shared cc.os"
>>> Pass 2: "S),(N.,N.,N.),()gcc -o libcc.so.0.1.0 -shared -Wl,-Bsymbolic
>>> -Wl,-soname=libcc.so.0 cc.osgcc -o libcc.so.0.1.0 -shared -Wl,-Bsymbolic
>>> -Wl,-soname=libcc.so.0 cc.os"
>>>
>>> What I see on the command line: "gcc -o libcc.so.0.1.0 -shared
>>> -Wl,-Bsymbolic -Wl,-soname=libcc.so.0 cc.os"
>>>
>>> Seems that the issue is that the symlink targets are getting turned into
>>> libcc.so Node rather than being there OWN node. We may need to add symlink
>>> handling to Node disambiguate?
>>>
>>> V/R,
>>> William
>>>
>>> On Sun, Jun 14, 2015 at 11:55 AM, William Blevins <wblevins001 at gmail.com
>>> > wrote:
>>>
>>>> I'm looking at the Node object code and I see that get_binfo gets
>>>> called twice for versioned shared libraries but the bactsig changes between
>>>> calls.
>>>>
>>>> I'll try and determine the delta.
>>>>
>>>> On Sat, Jun 6, 2015 at 6:55 PM, Paweł Tomulik <ptomulik at meil.pw.edu.pl>
>>>> wrote:
>>>>
>>>>> Ok, submitted: http://scons.tigris.org/issues/show_bug.cgi?id=3006
>>>>>
>>>>> W dniu 06.06.2015 o 22:23, Bill Deegan pisze:
>>>>> > Seems like a bug.
>>>>> > Please file with a simple reproducible test case.
>>>>> >
>>>>> > Thanks,
>>>>> > Bill
>>>>> >
>>>>> > On Sat, Jun 6, 2015 at 3:53 PM, Paweł Tomulik <
>>>>> ptomulik at meil.pw.edu.pl
>>>>> > <mailto:ptomulik at meil.pw.edu.pl>> wrote:
>>>>> >
>>>>> >
>>>>> > W dniu 06.06.2015 o 18:59, Bill Deegan pisze:
>>>>> > > What version of SCons are you running?
>>>>> >
>>>>> >
>>>>> > ptomulik at barakus:$ scons --version
>>>>> > SCons by Steven Knight et al.:
>>>>> > script: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
>>>>> > engine: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
>>>>> > engine path: ['/usr/local/lib/scons-2.3.4/SCons']
>>>>> > Copyright (c) 2001 - 2014 The SCons Foundation
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > > There have been some fixes since 2.3.4 for this code
>>>>> > > Can you try running the tip of default?
>>>>> >
>>>>> >
>>>>> > Tip (b6cecd171b57) does the same.
>>>>> >
>>>>> >
>>>>> > >
>>>>> > > -Bill
>>>>> > >
>>>>> > > On Fri, Jun 5, 2015 at 9:07 AM, Paweł Tomulik <
>>>>> ptomulik at meil.pw.edu.pl <mailto:ptomulik at meil.pw.edu.pl>
>>>>> > > <mailto:ptomulik at meil.pw.edu.pl <mailto:
>>>>> ptomulik at meil.pw.edu.pl>>>
>>>>> > wrote:
>>>>> > >
>>>>> > > I have this simple sconstruct:
>>>>> > >
>>>>> > > env = Environment()
>>>>> > > tgt = env.SharedLibrary('test', ['test.cpp'],
>>>>> > SHLIBVERSION='0.1.0')
>>>>> > > print tgt
>>>>> > >
>>>>> > > I observed, that the linking command is invoked each time I
>>>>> > run scons,
>>>>> > > which is wrong:
>>>>> > >
>>>>> > > ptomulik at barakus:$ scons -Q
>>>>> > > ['libtest.so.0.1.0']
>>>>> > > g++ -o libtest.so.0.1.0 -shared -Wl,-Bsymbolic
>>>>> > -Wl,-soname=libtest.so.0
>>>>> > > test.os
>>>>> > > ptomulik at barakus:$ scons -Q
>>>>> > > ['libtest.so.0.1.0']
>>>>> > > g++ -o libtest.so.0.1.0 -shared -Wl,-Bsymbolic
>>>>> > -Wl,-soname=libtest.so.0
>>>>> > > test.os
>>>>> > >
>>>>> > > debug=explain shows this:
>>>>> > >
>>>>> > > ptomulik at barakus:$ scons -Q --debug=explain
>>>>> > > ['libtest.so.0.1.0']
>>>>> > > scons: rebuilding `libtest.so.0.1.0' because the contents
>>>>> of
>>>>> > the build
>>>>> > > action changed
>>>>> > > action: SharedFlagChecker(target, source,
>>>>> env)
>>>>> > > VersionedSharedLibrary(target,
>>>>> source, env)
>>>>> > > g++ -o libtest.so.0.1.0 -shared -Wl,-Bsymbolic
>>>>> > -Wl,-soname=libtest.so.0
>>>>> > > test.os
>>>>> > >
>>>>> > >
>>>>> > > Is it something already known, or shall I submit a bug?
>>>>> > >
>>>>> > > Anyway, the SharedLibrary builder creates symlinks, but
>>>>> they
>>>>> > do not
>>>>> > > appear in the function result (tgt contains only the
>>>>> library).
>>>>> > Is this a
>>>>> > > bug or a feature? How can I guess what are the nodes
>>>>> produced
>>>>> > by the
>>>>> > > builder?
>>>>> > >
>>>>> > > --
>>>>> > > Pawel Tomulik
>>>>> > > _______________________________________________
>>>>> > > Scons-users mailing list
>>>>> > > Scons-users at scons.org <mailto:Scons-users at scons.org>
>>>>> > <mailto:Scons-users at scons.org <mailto:Scons-users at scons.org>>
>>>>> > > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > _______________________________________________
>>>>> > > Scons-users mailing list
>>>>> > > Scons-users at scons.org <mailto:Scons-users at scons.org>
>>>>> > > https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>> > >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Pawel Tomulik
>>>>> > _______________________________________________
>>>>> > Scons-users mailing list
>>>>> > Scons-users at scons.org <mailto: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
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> Pawel Tomulik
>>>>> _______________________________________________
>>>>> 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/20150614/395ad429/attachment-0001.html>
More information about the Scons-users
mailing list