David, I'm thinking the better list to send this to is the user's mailing list since this is an issue a user may run into, and not a discussion about SCons' development.
I'll cc that list and please use that going forward unless you are discussing SCons' development. Thanks, Bill On Tue, Sep 30, 2014 at 4:27 PM, David Gittins <dgitt...@liquidcapital.com> wrote: > 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 ( > mockbu...@c6b9.bsys.dev.centos.org) (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 link > <http://www.liquidcapital.com/group/index.php?location=/web/General/Disclaimer> > for terms relating to all email correspondence. > > > > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev