Info

If the ThinArchive tool is enabled, and you add a non-existent library to LIBDEPS, or create a library dependency cycle, you get an error like this: scons: *** [build/optdebug/mongo/mongo] TypeError : __class__ assignment: 'Entry' object layout differs from 'ThinArchiveNode' Instead of the expected scons: *** [build/optdebug/mongo/libbase.so] Implicit dependency `src/mongo/libasdf.so' not found, needed by target `build/optdebug/mongo/libbase.so'. scons: done building targets (errors occurred during build). That happens when the thin_archive.py tool hasn't been loaded.

Top User Comments

acm commented on Tue, 28 Feb 2017 03:03:40 +0000: We have disabled the thin archive tool for now, in the above commit, so this is no longer a pressing issue. We should still fix the Tool, but it is no longer a requirement for 3.5. xgen-internal-githook commented on Tue, 28 Feb 2017 03:02:43 +0000: Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@mongodb.com'} Message: SERVER-27380 Use response files for long lines, not thin_archive Branch: master https://github.com/mongodb/mongo/commit/27026169e795dc090e692fb27f93645e6646be48 gabriel.russell commented on Thu, 23 Feb 2017 16:48:48 +0000: There are several instances of the cast in FS.py, but the one we hit is: https://github.com/mongodb/mongo/blob/master/src/third_party/scons-2.5.0/scons-local-2.5.0/SCons/Node/FS.py#L1069 acm commented on Wed, 22 Feb 2017 23:10:50 +0000: gabriel.russell and jesse - Can you point to where in the SCons sources (preferably the ones embedded in the mongo sources) this cast is done? I'd like to understand a bit better what the problem is before I start thinking about solutions. gabriel.russell commented on Tue, 21 Feb 2017 20:00:46 +0000: With some help from jesse, I was able to get to the bottom of this problem. Python doesn't have casting, but there are ad hoc cast implementations that can be made to work in some situations, with some caveats. SCons does use one of these in some places, SCons.Node.FS., in particular. Within this cast implementation it's only possible to cast between direct sub classes of SCons.Node.Fs, which I think are just Entry, File and Dir. Subclasses of these subclasses cause the casting mechanism to fail outright. Because it breaks the casting, it doesn't look like it's OK to subclass SCons.Node.Fs., which is exactly what ThinArchiveNode does. I was previously thinking that we could just use an actual Scons.Node.Fs.File and override its nested class NodeInfo, but now I realize that just stores "signature" information, and doesn't effect how it's calculated. So I don't think we can use regular Scons.Node.Fs.File nodes for our thin archive nodes. Subclassing Scons.Node.Node does seam to be supported. There are examples of doing so, SCons/Node/Alias.py and SCons/Node/Python.py. It appears to me that subclassing Scons.Node.Node is the preferred way to create nonstandard scons nodes. acm commented on Wed, 15 Feb 2017 18:32:07 +0000: And I'll bet that the abilink tool only exhibits it in --link-model=dynamic mode. gabriel.russell commented on Wed, 15 Feb 2017 17:34:14 +0000: --link-model=object, --link-model=dynamic, also worked fine, but --link-model=static failed as this ticket explains. acm commented on Wed, 15 Feb 2017 17:00:11 +0000: Can you test this in all three linking modes (--link-model=object, --link-model=static, --link-model=dynamic). The issue may only affect some of those modes now that SERVER-27577 is fixed. gabriel.russell commented on Wed, 15 Feb 2017 16:47:20 +0000: I can't replicate this. With thin_archive.py being loaded, both non existent and circular LIBDEPS dependencies appear to cause correct errors. This patch causing a circular dependency: -env.Library("murmurhash3", ["MurmurHash3.cpp"]) +env.Library( + target="murmurhash3", + source=["MurmurHash3.cpp"], + LIBDEPS=[ '$BUILD_DIR/mongo/db/repl/bgsync' ], +) compiled: python ./buildscripts/scons.py -j$(grep -c ^processor /proc/cpuinfo) CC=/opt/mongodbtoolchain/v2/bin/gcc CXX=/opt/mongodbtoolchain/v2/bin/g++ OBJCOPY=/opt/mongodbtoolchain/v2/bin/objcopy --link-model=dynamic give: scons: *** [build/opt/mongo/mongod] Library dependency cycle detected: build/opt/mongo/libbase.so => build/opt/third_party/murmurhash3/libmurmurhash3.so => build/opt/mongo/db/repl/libbgsync.so => build/opt/mongo/db/repl/libdata_replicator_external_state_impl.so => build/opt/mongo/db/repl/liboptime.so => build/opt/mongo/libbase.so scons: building terminated because of errors. build/opt/mongo/mongod failed: Library dependency cycle detected: build/opt/mongo/libbase.so => build/opt/third_party/murmurhash3/libmurmurhash3.so => build/opt/mongo/db/repl/libbgsync.so => build/opt/mongo/db/repl/libdata_replicator_external_state_impl.so => build/opt/mongo/db/repl/liboptime.so => build/opt/mongo/libbase.so and with this patch causing a missing dependency: -env.Library("murmurhash3", ["MurmurHash3.cpp"]) +env.Library( + target="murmurhash3", + source=["MurmurHash3.cpp"], + LIBDEPS=[ '$BUILD_DIR/mofongo' ], +) compiled similarly, gives: scons: *** [build/opt/third_party/murmurhash3/libmurmurhash3.so] Implicit dependency `src/libmofongo.so' not found, needed by target `build/opt/third_party/murmurhash3/libmurmurhash3.so'. scons: building terminated because of errors. build/opt/third_party/murmurhash3/libmurmurhash3.so failed: Implicit dependency `src/libmofongo.so' not found, needed by target `build/opt/third_party/murmurhash3/libmurmurhash3.so'. acm commented on Wed, 4 Jan 2017 14:53:53 +0000: This also applies to the abilink.py tool. The issue should be fixed in both.

Steps to Reproduce