[Scons-users] Need help debugging my build

Wed Jun 10 16:51:53 EDT 2015

Now that I have seen the tigris issue, I realize I have seen this before.

This bug has been around a while I think.  I use InstallVersionedLib
instead (because of that issue), but it may not serve your purpose.

V/R,
William

On Wed, Jun 10, 2015 at 9:01 AM, Ganssauge, Gottfried <
Gottfried.Ganssauge at haufe-lexware.com> wrote:

>  I think I can now verify that my problem doesn’t depend on my homegrown
> packaging at all.
>
> When I just do
>
> Alias (‘packages’, [<lib in question>], “echo $SOURCE”)
>
> it behaves the same – trying to relink the library before printing it’s
> name.
>
>
>
> So this seems to be a case of the recently reported bug
> http://scons.tigris.org/issues/show_bug.cgi?id=3006
>
>
>
> Cheers,
>
> Gottfried
>
>
>
> *Von:* Scons-users [mailto:scons-users-bounces at scons.org] * Im Auftrag
> von *William Blevins
> *Gesendet:* Freitag, 5. Juni 2015 00:40
>
> *An:* SCons users mailing list
> *Betreff**:* Re: [Scons-users] Need help debugging my build
>
>
>
> As a heads-up, scons 2.3.4 has updated documentation for those functions.
>
>
>
> V/R,
>
> William
>
>
>
> On Thu, Jun 4, 2015 at 12:52 PM, Ganssauge, Gottfried <
> Gottfried.Ganssauge at haufe-lexware.com> wrote:
>
>  I would like to – really J
> But I’m using neither – but some homegrown function instead.
>
> The only excuse for that is my build being almost 12 years old started
> even before the first scons release – shortly after the Software
> Carpentry competition was completed.
>
> I was really convinced of the concept and immediately started rewriting my
> build which was Makefile based before.
>
> Therefore there still is a lot of homegrown stuff which in the meantime
> made it to SCons itself – only differently.
>
>
>
> But yes – I suspect this is the area where my problem comes from.
>
> I try to migrate to InstallVersionedLibrary and look if that will solve
> my problem.
>
>
>
> Thanks again,
>
> Gottfried
>
>
>
> *Von:* Scons-users [mailto:scons-users-bounces at scons.org] *Im Auftrag von
> *William Blevins
> *Gesendet:* Donnerstag, 4. Juni 2015 18:21
>
>
> *An:* SCons users mailing list
> *Betreff**:* Re: [Scons-users] Need help debugging my build
>
>
>
> Can you give us a snippet of how you are making the VersionLibrary
> commands (IE. SConstruct/SConscript)?
>
>
>
> I prefer to use the InstallVersionLibrary over the Builder command.
>
>
>
> V/R,
>
> William
>
>
>
> On Thu, Jun 4, 2015 at 11:51 AM, Ganssauge, Gottfried <
> Gottfried.Ganssauge at haufe-lexware.com> wrote:
>
>  Thanks.
>
> Unfortunately the issue  seems to be something else – that patch doesn’t
> change that behavior.
>
> I’m actually coming from scons-2.3.1 because I still have to support
> systems where only python-2.4 is available.
>
> In scons-local-2.3.1 the same problem occurs.
>
>
>
> But you’ve given me something to think about anyway …
>
>
>
> Cheers,
>
> Gottfried
>
>
>
> *Von:* Scons-users [mailto:scons-users-bounces at scons.org] *Im Auftrag von
> *William Blevins
> *Gesendet:* Donnerstag, 4. Juni 2015 17:46
>
>
> *An:* SCons users mailing list
> *Betreff**:* Re: [Scons-users] Need help debugging my build
>
>
>
> Sorry, I meant scons-2.3.3.
>
>
>
> Please see
> https://bitbucket.org/scons/scons/commits/e572f413419a261080549213148ea875b9685a50
>
>
>
> If for some reason you cannot follow that link see pull request #227
>
>
>
> V/R,
>
> William
>
>
>
> On Thu, Jun 4, 2015 at 11:26 AM, Ganssauge, Gottfried <
> Gottfried.Ganssauge at haufe-lexware.com> wrote:
>
>  Do you happen to know where I could have a look at that patch?
>
> I know I haven’t given you terribly much to think about – but this was an
> idea I already stumbled upon myself, so I would like to check that patch
> out...
>
>
>
> I really tried hard to use –tree=status, but all I can read from it is
> that the intermediate library isn’t current whereas all it’s dependencies
> are.
> Interestingly **only** that library isn’t current – the nodes dependent
> on it **are** current.
>
>
>
> [E B   C  ]  |   | +-OptiSearch/package/linux-x86_64-gcc/lib/libosr.so.1
>
> [E B   C  ]  |   | | +-OptiSearch/package/linux-x86_64-gcc/lib/libosr.so
>
> [E B   C  ]  |   | |   +-OptiSearch
> /package/linux-x86_64-gcc/lib/libosr.so.10.0.2768
>
> [E B      ]  |   | |
> +-OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768
>
> [E B   C  ]  |   | |     | +-OptiSearch/src/shlib
> /linux-x86_64-gcc/Release/dummy.os
>
> [E     C  ]  |   | |     |   +-OptiSearch/src/osdb/dummy.cpp
>
> [E     C  ]  |   | |     |   +-/usr/bin/g++
>
> [E     C  ]  |   | |     +-/bin/chmod
>
>
>
> The same pattern repeats for all the symlinks of the library.
>
>
>
> My conclusion so far was that something seems to be wrong with signature
> processing – but I didn’t find out where to set my breakpoints or do print
> outs to verify my assumption.
>
>
>
> What do you mean with “rolling back to 2.4.3”?
> Python-2.4.3? no.
> Do you mean scons-2.3.4? I do use that already.
>
>
>
> Thanks,
>
>
> Gottfried
>
>
>
>
>
> *Von:* Scons-users [mailto:scons-users-bounces at scons.org] *Im** Auftrag
> von * William Blevins
> *Gesendet**:* Donnerstag, 4. Juni 2015 17:11
> *An:* SCons users mailing list
> *Betreff**:* Re: [Scons-users] Need help debugging my build
>
>
>
> Actually, it may be related specifically to how symlinks are copied.
>
>
>
> I know there is a patch for it that will be available in the next
> release.  Try rolling back to 2.4.3.
>
>
>
> V/R,
>
> William
>
>
>
> On Thu, Jun 4, 2015 at 11:09 AM, William Blevins <wblevins001 at gmail.com>
> wrote:
>
>  I'm not sure how we can help.  You haven't provided us with much context.
>
>
>
> In general, you can debug your build using "--debug" and "--tree"
> options.  Please see the User's Guide.
>
>
>
> V/R,
>
> William
>
>
>
> On Thu, Jun 4, 2015 at 10:31 AM, Ganssauge, Gottfried <
> Gottfried.Ganssauge at haufe-lexware.com> wrote:
>
>   My build – which is somewhat large – normally runs fine using
> scons-local-2.3.4 with python2.7.6 on Ubuntu Linux-14.04
>
>
>
> But when I’m starting the same build twice in a row I’d expect it to
> rebuild nothing at all the second time through.
> The actual targets which I request aren’t rebuilt in fact but some
> intermediate targets.
>
>
>
> For example:
>
>
>
> gotti at manta ~/source/sourcecode-cd $ scons packages
>
> scons: Reading SConscript files ...
>
> ... Lots of configuration checks removed ...
>
> scons: done reading SConscript files.
>
> scons: Building targets ...
>
> Linking OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768
>
> Linking
> OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768
>
> Linking
> OptiSearch/src/osrtcl/linux-x86_64-gcc/Release/libosrtcl.so.6.0.2768
>
> OptiSearch/src/osrtcl/linux-x86_64-gcc/Release/osdb.os: In function `
> mkworkdir':
>
> /home/gotti/source/sourcecode-cd/OptiSearch/src/cp-iface/osdb.cpp:438:
> warning: the use of `tempnam' is dangerous, better use `mkstemp'
>
> OptiSearch/src/osrtcl/linux-x86_64-gcc/Release/osdb.os: In function `
> mkdtemp':
>
> /home/gotti/source/sourcecode-cd/OptiSearch/src/cp-iface/osdb.cpp:199:
> warning: the use of `mktemp' is dangerous, better use `mkstemp'
>
> or `mkdtemp'
>
> Linking HitSort/linux-x86_64-gcc/Release/libhitsort.so.5.0.2768
>
> Linking OSI/osidll/linux-x86_64-gcc/Release/libosi.so.9.0.2768
>
> Linking OSI/adust/linux-x86_64-gcc/Release/libadjustdll.so.9.0.2768
>
> Linking
> OSI/gen_updatedb/linux-x86_64-gcc/Release/libgenupdatedb.so.1.0.2768
>
> Linking OSI/ositcl/linux-x86_64-gcc/Release/libositcl.so.6.0.2768
>
> scons: `packages' is up to date.
>
> scons: done building targets.
>
> gotti at manta ~/source/sourcecode-cd $ scons/scons.py --debug=explain
> packages
>
> scons: Reading SConscript files ...
>
> ... Lots of configuration checks removed ...
>
> scons: done reading SConscript files.
>
> scons: Building targets ...
>
> scons: rebuilding
> `OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768' because
> the contents of the build action changed
>
>                action: SharedFlagChecker(target, source, env)
>
>                        VersionedSharedLibrary(target, source, env)
>
> Linking OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768
>
> scons: rebuilding
> `OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768'
> because:
>
>
> `OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768' is no
> longer a dependency
>
>
> `OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768' is a
> new dependency
>
> Linking
> OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768
>
> scons: rebuilding
> `OptiSearch/src/osrtcl/linux-x86_64-gcc/Release/libosrtcl.so.6.0.2768'
> because:
>
>
> `OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768' is
> no longer a dependency
>
>
> `OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768' is no
> longer a dependency
>
>
> `OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768' is
> a new dependency
>
>
> `OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768' is a
> new dependency
>
> Linking
> OptiSearch/src/osrtcl/linux-x86_64-gcc/Release/libosrtcl.so.6.0.2768
>
> OptiSearch/src/osrtcl/linux-x86_64-gcc/Release/osdb.os: In function `
> mkworkdir':
>
> /home/gotti/source/sourcecode-cd/OptiSearch/src/cp-iface/osdb.cpp:438:
> warning: the use of `tempnam' is dangerous, better use `mkstemp'
>
> OptiSearch/src/osrtcl/linux-x86_64-gcc/Release/osdb.os: In function `
> mkdtemp':
>
> /home/gotti/source/sourcecode-cd/OptiSearch/src/cp-iface/osdb.cpp:199:
> warning: the use of `mktemp' is dangerous, better use `mkstemp'
>
> or `mkdtemp'
>
> scons: rebuilding `HitSort/linux-x86_64-gcc/Release/libhitsort.so.5.0.2768'
> because the contents of the build action changed
>
>                action: SharedFlagChecker(target, source, env)
>
>                        VersionedSharedLibrary(target, source, env)
>
> Linking HitSort/linux-x86_64-gcc/Release/libhitsort.so.5.0.2768
>
> scons: rebuilding `OSI/osidll/linux-x86_64-gcc/Release/libosi.so.9.0.2768'
> because:
>
>
> `OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768' is
> no longer a dependency
>
>
> `OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768' is
> a new dependency
>
> Linking OSI/osidll/linux-x86_64-gcc/Release/libosi.so.9.0.2768
>
> scons: rebuilding `OSI/adust/linux-x86_64-gcc/Release/libadjustdll.so.9.0.2768'
> because:
>
>
> `OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768' is
> no longer a dependency
>
>
> `OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768' is
> a new dependency
>
> Linking OSI/adust/linux-x86_64-gcc/Release/libadjustdll.so.9.0.2768
>
> scons: rebuilding
> `OSI/gen_updatedb/linux-x86_64-gcc/Release/libgenupdatedb.so.1.0.2768'
> because:
>
>
> `OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768' is no
> longer a dependency
>
>
> `OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768' is
> no longer a dependency
>
>
> `OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768' is a
> new dependency
>
>
> `OptiSearch/src/tools/linux-x86_64-gcc/Release/libosrtools.so.5.0.2768' is
> a new dependency
>
> Linking
> OSI/gen_updatedb/linux-x86_64-gcc/Release/libgenupdatedb.so.1.0.2768
>
> scons: rebuilding `OSI/ositcl/linux-x86_64-gcc/Release/libositcl.so.6.0.2768'
> because:
>
>            `OSI/osidll/linux-x86_64-gcc/Release/libosi.so.9.0.2768' is no
> longer a dependency
>
>            `OSI/osidll/linux-x86_64-gcc/Release/libosi.so.9.0.2768' is a
> new dependency
>
> Linking OSI/ositcl/linux-x86_64-gcc/Release/libositcl.so.6.0.2768
>
> scons: `packages' is up to date.
>
> scons: done building targets.
>
> gotti at manta ~/source/sourcecode-cd $
>
> The same happens when I’m doing the same build several times in a row.
>
> When I’m instead running “scons
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768” nothing
> is rebuilt:
>
> (gotti at manta 1059) scons
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768 | fgrep
> -v Checking
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: Nothing to be done for
> `OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768'.
> scons: done building targets.
> (gotti at manta 1060)
>
> So far so bad.
>
> From the explanation above I take it, that somehow the signature changes
> with each linker run, but sconsigns says otherwise:
>
> $ scons/sconsign.py .sconf_temp/linux-x86_64-gcc/signatures.dblite | fgrep
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768  | sort |
> uniq –c
>       1
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768:
> abc0198cce2ea39815990d15a269b25d 1433421673 6658337
>      29
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768:
> abc0198cce2ea39815990d15a269b25d 1433425407 6658337
>      22
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768:
> abc0198cce2ea39815990d15a269b25d 1433427119 6658337
>
> After rebuild only 22 of the occurences are updated – and it’s only the
> timestamp
>
> $ scons/sconsign.py .sconf_temp/linux-x86_64-gcc/signatures.dblite | fgrep
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768  | sort |
> uniq -c
>       1
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768:
> abc0198cce2ea39815990d15a269b25d 1433421673 6658337
>      29
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768:
> abc0198cce2ea39815990d15a269b25d 1433425407 6658337
>      22
> OptiSearch/src/shlib/linux-x86_64-gcc/Release/libosr.so.10.0.2768:
> abc0198cce2ea39815990d15a269b25d 1433427485 6658337
>
> That’s the point where I need some help.
>
> Why is it that the same derived library is contained in signatures.dblite
> multiple time with differing timestamps?
>
> Why is it that only some of the occurences are updated?
>
> Why is it that the packages target (which is an alias for debian packages
> of all stuff built) is not rebuilt although intermediate files are?
>
> I already tried hard to reduce the size of the built to produce a simpler
> example, but to no avail – the problem doesn’t happen with smaller builds
> L
>
> I’m quite capable in debugging python code, but I could really use some
> help with tips or hints where to look …
>
>
>
> Cheers,
>
> Gottfried Ganßauge
>
> Entwickler
> Content Engineering & Development
>
>
>
> ------------------------------------------------------------------
>
> *Haufe-Lexware GmbH & Co. KG*
>
> *Ein Unternehmen der Haufe Gruppe*
>
> Munzinger Str. 9, 79111 Freiburg
>
> Tel. +49 761 898-0
>
> E-Mail: Gottfried.Ganssauge at haufe-lexware.com
>
> Internet: http://www.haufe-lexware.com
>
> ------------------------------------------------------------------
>
> Kommanditgesellschaft, Sitz und Registergericht Freiburg, HRA 4408
>
> Komplementäre: Haufe-Lexware Verwaltungs GmbH,
>
> Sitz und Registergericht Freiburg, HRB 5557; Martin Laqua
>
> Beiratsvorsitzende: Andrea Haufe
>
> Geschäftsführung: Isabel Blank, Markus Dränert, Jörg Frey,
>
> Birte Hackenjos, Randolf Jessl, Markus Reithwiesner,
>
> Joachim Rotzinger, Dr. Carsten Thies
>
> ------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20150610/359f3450/attachment-0001.html>