[Scons-users] [Scons-dev] Problems with VersionedSharedLibrary

[Bill Deegan]

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 <dgittins at 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 (
> mockbuild at 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 at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20140930/700adb5d/attachment-0001.html>