[Scons-dev] Problems with VersionedSharedLibrary

[David Gittins]

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 <a href=http://www.liquidcapital.com/group/index.php?location=/web/General/Disclaimer>link</a> for terms relating to all email correspondence.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20141001/39c9c78f/attachment-0001.html>