[Scons-users] InstallVersionedLibrary sometimes fails when symlinking

[William Deegan]

Andrew,


> Were you able to repro this? If so, should I file a ticket?


Unfortunately, very busy IRL at the moment so haven't had a chance to try it out.
Lots of work leading up to a conference, once that's over (6/6) I'll have some time to take a look at this.


> 

> Also, is there some documentation on the SCons bugfix and release cycle? I've noticed that there are only infrequently 'z +1' releases of SCons x.y.z. If the problem with InstallVersionedLibrary is legitimate, should I expect to see a fix in a to-be-released-somewhat-soonish SCons 2.3.1 bugfix release, or longer term in some future SCons 2.4 release?



SCons is a volunteer run open source project.
If you want to ensure that a fix is made, you'll either have to submit a fix, hope that someone in the community picks up the issue and fixes it, or finance a consultant to resolve the issue for you.

In general we will release a new version either when something notable has been fixed or if there's been a sufficient number of small fixes.
If a fix is submitted for your issue (assuming it's not user error (which from a cursory glance it doesn't look like it is)), then it would be in the next release.

Also keep in mind all the work is done in a public mercurial repo hosted on bitbucket, so as soon as anyone published a fix you can try it against your build, and use that code if it resolves your issue.

-Bill


> 

> Thanks,

> Andrew

> 

> 

> 

> On Fri, May 24, 2013 at 4:36 PM, Andrew C. Morrow <andrew.c.morrow at gmail.com> wrote:

> 

> Well, the complete example I posted above was on OS X Mountain Lion. But I'm experiencing the same problem on Linux. My first email with the strace output was from Ubuntu 13.04.

> 

> 

> On Fri, May 24, 2013 at 4:04 PM, Bill Deegan <bill at baddogconsulting.com> wrote:

> What platform are you on?

> 

> -Bill

> 

> 

> On Fri, May 24, 2013 at 7:16 AM, Andrew C. Morrow <andrew.c.morrow at gmail.com> wrote:

> 

> Here is a complete example demonstrating the problem

> 

> SConstruct:

> 

> EnsureSConsVersion(2, 3, 0)

> 

> AddOption('--prefix',

>           dest='prefix',

>           type='string',

>           nargs=1,

>           action='store',

>           metavar='DIR',

>           help='installation prefix')

> 

> env = Environment(

>     tools = ["default"],

>     PREFIX = GetOption('prefix'))

> 

> env.SConscript('src/SConscript', variant_dir='build', exports=['env'])

> 

> 

> 

> src/SConscript:

> 

> Import('env')

> 

> sources = [

>     'foo.cpp',

> ]

> 

> headers = [

>     'foo.hpp'

> ]

> 

> sharedLibEnv = env.Clone(SHLIBVERSION='0.1.2')

> sharedLib = sharedLibEnv.SharedLibrary(

>     target='foo',

>     source=sources,

> )

> 

> sharedLibEnv.InstallVersionedLib("$PREFIX/lib", sharedLib)

> sharedLibEnv.Install("$PREFIX/include", headers)

> 

> 

> src/foo.hpp:

> 

> #include <iosfwd>

> 

> namespace foo {

> 

>     void say_hello(std::ostream& stream);

> 

> } // namespace foo

> 

> 

> src/foo.cpp:

> 

> #include "foo.hpp"

> 

> #include <ostream>

> 

> namespace foo {

> 

>     void say_hello(std::ostream& stream) {

>         stream << "Hello, World!\n";

>     }

> 

> } // namespace foo

> 

> 

> 

> OK, so now build the 'install' target, specifying some prefix:

> 

> scons --prefix=$(pwd)/install install

> scons: Reading SConscript files ...

> scons: done reading SConscript files.

> scons: Building targets ...

> Install file: "build/foo.hpp" as "install/include/foo.hpp"

> g++ -o build/foo.os -c -fPIC build/foo.cpp

> g++ -o build/libfoo.0.1.2.dylib -dynamiclib -current_version 0.1.2 -compatibility_version 0.1.2 -undefined dynamic_lookup build/foo.os

> Install file: "build/libfoo.0.1.2.dylib" as "install/lib/libfoo.0.1.2.dylib"

> scons: done building targets.

> 

> Now, make a trivial change to foo.cpp to force a relink (like change the string), and rebuild:

> 

> scons --prefix=$(pwd)/install install

> scons: Reading SConscript files ...

> scons: done reading SConscript files.

> scons: Building targets ...

> g++ -o build/foo.os -c -fPIC build/foo.cpp

> g++ -o build/libfoo.0.1.2.dylib -dynamiclib -current_version 0.1.2 -compatibility_version 0.1.2 -undefined dynamic_lookup build/foo.os

> Install file: "build/libfoo.0.1.2.dylib" as "install/lib/libfoo.0.1.2.dylib"

> scons: *** [install/lib/libfoo.0.1.2.dylib] File exists

> scons: building terminated because of errors.

> 

> The build fails while trying to symlink.

> 

> Thanks,

> Andrew

> 

> 

> 

> On Thu, May 23, 2013 at 1:30 PM, Andrew C. Morrow <andrew.c.morrow at gmail.com> wrote:

> 

> Hi -

> 

> I've recently been experimenting with the new versioned shared library support in SCons 2.3.0, which so far looks really nice, so thanks for that.

> 

> I have, I think, found one issue, which is that it appears that if you

> 

> - have used InstallVersionedLibrary and produced a target and symlink chain in your install directory

> - update a dependency such that the library is rebuilt

> - reinstall

> 

> The build fails while attempting to write the symlinks. For my build this looks like:

> 

> scons: done reading SConscript files.

> scons: Building targets ...

> Install file: "client_build/libfoo.so.2.3.4" as "/dev/opt/lib/libfoo.so.2.3.4"

> scons: *** [/dev/opt/lib/libfoo.so.2.3.4] File exists

> 

> Running under strace, it is clear that the attempt to create the symlink is failing because it already exists in the install directory.

> 

> pid 22278] stat("client_build/libfoo.so.2.3.4", {st_mode=S_IFREG|0755, st_size=20255704, ...}) = 0

> [pid 22278] utimes("/dev/opt/lib/libfoo.so.2.3.4", {{1369328366, 0}, {1369328365, 0}}) = 0

> [pid 22278] chmod("/dev/opt/lib/libfoo.so.2.3.4", 0755) = 0

> [pid 22278] stat("client_build/libfoo.so.2.3.4", {st_mode=S_IFREG|0755, st_size=20255704, ...}) = 0

> [pid 22278] chmod("/dev/opt/lib/libfoo.so.2.3.4", 0755) = 0

> [pid 22278] symlink("libfoo.so.2.3.4", "/dev/opt/lib/libfoo.so") = -1 EEXIST (File exists)

> 

> I think the same thing can occur in the build directory as well. If I remove client_build/libfoo.so.2.3.4 and rebuild, I get a similar error and strace:

> 

> scons: Building targets ...

> generate_buildinfo(["build/buildinfo.cpp"], ['\n#include <string>\n#include <boost/version.hpp>\n\n#include "mongo/util/version.h"\n\nnamespace mongo {\n    const char * gitVersion() { return "%(git_version)s"; }\n    const char * compiledJSEngine() { return "%(js_engine)s"; }\n    const char * allocator() { return "%(allocator)s"; }\n    const char * loaderFlags() { return "%(loader_flags)s"; }\n    const char * compilerFlags() { return "%(compiler_flags)s"; }\n    std::string sysInfo() { return "%(sys_info)s BOOST_LIB_VERSION=" BOOST_LIB_VERSION ; }\n}  // namespace mongo\n'])

> g++ <library-rebuild>

> scons: *** [client_build/libfoo.so.2.3.4] File exists

> 

> strace shows a similar EEXIST error in a call to symlink.

> 

> Thanks,

> Andrew

> 

> 

> 

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

> 

> 

> 

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

> 

> 

> 

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20130527/d7e548df/attachment.htm