[Scons-users] Need help debugging my build

Wed Jun 10 09:01:29 EDT 2015

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<mailto:Gottfried.Ganssauge at haufe-lexware.com>> wrote:
I would like to – really ☺
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<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<mailto: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<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<mailto: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<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

_______________________________________________
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<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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150610/3ceece94/attachment-0001.html>