Hi guys, I am running SCons 2.3.1 and converting a project to make use of it, with great success.
I just wanted to report some issues I have had with VersionedSharedLibrary which have, ultimately, led me to cut it out entirely. Before raising bug reports I thought I should ask here in case this is all known already. I couldn't find these issues on the tigris bug tracker, so apologies if I have missed it... > scons --version SCons by Steven Knight et al.: script: v2.3.1, 2014/03/02 14:18:15, by garyo on lubuntu engine: v2.3.1, 2014/03/02 14:18:15, by garyo on lubuntu > cat /proc/version Linux version 2.6.32-431.20.3.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Thu Jun 19 21:14:45 UTC 2014 We are building a large set of shared libraries and binaries using gcc (specifically g++ and ld). The default action list for SharedLibrary (at least on this version in our setup) is [SharedCheck, ShLibAction]. The ShLibAction is actually a FunctionAction that calls the function VersionedSharedLibrary. That function, in turn, handles the SONAME and symlink stuff (if SHLIBVERSION is set) and invokes ShLinkAction, which runs the actual linker command line. Now the problems I've had: 1. When SHLIBVERSION is defined, VersionedSharedLibrary adds "-Wl,-Bsymbolic" to SHLINKFLAGS. I don't know why this is done but it completely broke our build. To get around this I actually had to hack SHLINKCOM to remove SHLINKFLAGS , and put my linker flags in a different variable! (I later gave up on using SHLIBVERSION, see below) 2. When SHLIBVERSION is defined, the symlinks are created, but doing a clean only removes the files and does not remove the symlinks. Later, a library dependency may be resolved by finding the (broken) symlink and lead to confusing link errors. I had to do more thorough manual cleans in some cases to remove the symlinks (I later gave up on using SHLIBVERSION, see below) 3. With OR without SHLIBVERSION, I would quite often get "found dependency cycle" errors on exit. I never managed to figure out exactly how to reproduce them but they appeared to be harmless. When I cut VersionedSharedLibrary out of the loop (see below), they simply stopped appearing... 4. I register a function with atexit which calls GetBuildFailures and prints the command lines of all failures. Unfortunately when a shared library link fails, the "command" member of the object we get from GetBuildFailures is None. Looking in the SCons code it became clear why: ShLinkAction does return a BuildError containing the real command line, which is then returned by VersionedSharedLibrary, but then when we get to SCons/Action.py:1077 (in FunctionAction.execute) it over-writes the command line with an attempt to represent the function call as a string. Perhaps FunctionAction should check whether the BuildError already contains a command line, and if so, leave it alone? I worked around all these issues like this: import SCons.Defaults env['BUILDERS']['SharedLibrary'].action = SCons.Action.Action(SCons.Defaults.ShLinkAction) This cuts out the SharedCheck, which in our setup it doesn't do anything useful (we already had to pacify it by setting STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME=1). More importantly it replaces ShLibAction with ShLinkAction, so VersionedSharedLibrary is never called. That makes issues 3 and 4 disappear and removes support for SHLIBVERSION. When I want versioned libraries with symlinks, I now achieve that with my own builders which add the symlinks as nodes that depend on their target. These then appear in the tree and get cleaned correctly, which eliminates issue 2. My builders also abstract the linker options to some other environment entries which I can set when doing the gcc configuration, avoiding issue 1. (I was also a bit concerned that gcc-specific command line syntax "-Wl,..." was built in to VersionedSharedLibrary...) Apologies for not providing files to reproduce this all neatly, etc. I am hoping that issues 1, 2 and 4 are obvious from inspection, and I never managed to reliably reproduce issue 3. Cheers Dave PS: Congratulations to everyone who has worked on SCons - I think it's great and it will be adding lots of value for us! Liquid Capital Australia Pty Limited is registered with the Australian Securities and Investment Commission and located in Australia. Liquid Capital Investments Hong Kong Limited and Liquid Capital Markets Hong Kong Limited are registered and located in Hong Kong. Liquid Capital Markets Hong Kong Limited is registered with the Securities and Futures Commission in Hong Kong. For more information about these companies, please contact + 61 2 8231 1159. Please click this <a href=http://www.liquidcapital.com/group/index.php?location=/web/General/Disclaimer>link</a> for terms relating to all email correspondence.
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
