[Scons-users] Need help debugging my build
Ganssauge, Gottfried
Gottfried.Ganssauge at haufe-lexware.com
Thu Jun 4 11:26:03 EDT 2015
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<mailto: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<mailto: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 ☹
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<mailto: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<mailto: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/20150604/adeb1bbc/attachment-0001.html>
More information about the Scons-users
mailing list