[Scons-users] SHLIBVERSION questions
William Blevins
wblevins001 at gmail.com
Sun Jun 14 14:01:37 EDT 2015
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/b60ed801/attachment-0001.html>
More information about the Scons-users
mailing list