[Scons-users] using g++ vs. gcc for linking when used with Repository()

taf.undying at gmx.de taf.undying at gmx.de
Thu Aug 9 09:20:39 EDT 2012


I get some weird link errors and don't know if this is a bug or if I am doing something wrong. So maybe you can help.

Assuming the following, simple folder setup:

+-.
+-local
| +-sconstruct
+-remote
+-main.cpp
+-sconstruct

main.cpp only contains a simple hello world example:


> #include <iostream>

>

> int main(int argc, char* argv[])

> {

> std::cout << "Hello, World!" << std::endl;

> return 0;

> }


And the sconstruct files (both) only contain a simple target definition for a program:


> env = Environment()

> env.Program('test', ['main.cpp'])


Now, if I run "scons" in the "remote" directory, first g++ is used to compile "main.cpp" to "main.o" and then g++ is used again to link it to the executable "test".

After that, I run the command "scons -Y ../remote" in the "local" directory.
Then scons tries to link the executable again (although I think it really should not, as nothing has changed). But this time, it uses gcc instead of g++. This results in "undefined reference" errors, as the STL library is not linked.

Trying different varations of that setup, I can say that it basically boils down to whether the object file "main.o" is in the local directory or whether it is only remote.
If it is local, then g++ is used for linking, but if the object file is remote, then scons tries to link using gcc, which fails.

I have tested this on linux with the following scons versions:


> SCons by Steven Knight et al.:

> script: v2.0.1.r5134, 2010/08/16 23:02:40, by bdeegan on cooldog

> engine: v2.0.1.r5134, 2010/08/16 23:02:40, by bdeegan on cooldog

> Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 > The SCons Foundation




> SCons by Steven Knight et al.:

> script: v2.2.0.issue-2856:2676:d23b7a2f45e8[MODIFIED], 2012/08/05 15:38:28, by garyo on oberbrunner-dev

> engine: v2.2.0.issue-2856:2676:d23b7a2f45e8[MODIFIED], 2012/08/05 15:38:28, by garyo on oberbrunner-dev

> engine path: ['/usr/lib/python2.7/site-packages/SCons']

> Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, > 2011, 2012 The SCons Foundation


Has anyone else seen this behaviour? And is this caused by something, that I am doing wrong? Or is it a bug?

Thanks in advance.

Daniel


More information about the Scons-users mailing list