[Scons-users] SHLIBVERSION questions

[William Blevins]

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/109df969/attachment.html>