[Scons-users] SCons / Make object files get mixed up

[William Blevins]

On Tue, Dec 8, 2015 at 4:41 PM, Petteri Hintsanen <petterih at iki.fi> wrote:

> Hello,
>
> I'm working on a C++ project that uses both Make and SCons.  Makefiles
> compile object code into the same directory where the corresponding
> sources are.  Most of the modules are built with either Make or SCons,
> not both.  But there is one module that can be build with Make or SCons.
> With this module, if Make has executed before SCons, SCons tries to use
> an object file produced by Make.  For example:
>

This makes sense if the source file has not changed, and the object file
has changed or the names/number of object files for the lib/exec in
question has changed. SCons will not rebuild the object; thus, SCons will
rebuild the lib/bin using the updated objects.

There was a request to make SCons check if intermediate and leaf nodes had
been modified outside the SCons build context and rebuild them if they had
been. I started a patch for this, but I never really got any feedback.
https://bitbucket.org/scons/scons/pull-requests/240/added-support-for-detecting-corruption/diff


>
> ~$ scons -Q build/debug/radarsimu/playback
> gcc -o build/debug/radarsimu/playback radarsimu/Playback.o
> /usr/bin/ld: radarsimu/Playback.o: undefined reference to symbol
> '__cxa_free_exception@@CXXABI_1.3'
> //usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO
> missing from command line
> collect2: error: ld returned 1 exit status
> scons: *** [build/debug/radarsimu/playback] Error 1


> Here radarsimu is the module I'm trying to build with variant_dir =
> "build/debug", and playback is one of binaries in that module.  The
> object file radarsimu/Playback.o has been compiled by Make.  (For
> clarity I have trimmed out libraries and other flags from the gcc
> command line.)  Another strange thing is that scons is executing gcc
> instead of g++.
>


SCons uses the file extension (IE. scanner keys) to determine which
builders are appropriate. SCons (by default) considers *.o source to be a C
object versus a CPP object if I am not mistaken. Context may be important
here.


>
> With --tree switch I get:
>
> ~$ scons -Q --tree=all,status build/debug/radarsimu/playback
> gcc -o build/debug/radarsimu/playback radarsimu/Playback.o
> /usr/bin/ld: radarsimu/Playback.o: undefined reference to symbol
> '__cxa_free_exception@@CXXABI_1.3'
> //usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO
> missing from command line
> collect2: error: ld returned 1 exit status
> scons: *** [build/debug/radarsimu/playback] Error 1
> E         = exists
>  R        = exists in repository only
>   b       = implicit builder
>   B       = explicit builder
>    S      = side effect
>     P     = precious
>      A    = always build
>       C   = current
>        N  = no clean
>         H = no cache
>
> [ RB      ]+-build/debug/radarsimu/playback
> [ RB   C  ]  +-build/debug/radarsimu/Playback.o
> [ R    C  ]  | +-radarsimu/Playback.cpp
> [E     C  ]  | +-/usr/bin/g++
> [E     C  ]  +-/usr/bin/gcc
> ( ... snipped off libraries ... )
>
>
> There are no files in build/debug/radarsimu but, if I understand the
> above correctly, SCons assumes that radarsimu/Playback.o is actually
> under the (variant) directory build/debug.
>
> If I remove radarsimu/Playback.o, everything goes well:
>
> ~$ rm radarsimu/Playback.o
> ~$ scons -Q build/debug/radarsimu/playback
> g++ -o build/debug/radarsimu/Playback.o -c radarsimu/Playback.cpp
> g++ -o build/debug/radarsimu/playback build/debug/radarsimu/Playback.o
>
>
>
> It might very well be that the reason for this odd behaviour is
> somewhere else in the build configuration, especially since I have not
> been able to reproduce this problem with a simpler example.  But I would
> be grateful if someone more experienced SCons user could point out what
> could cause this kind of behaviour.
>
> SCons version is 2.3.0.
>
> Thanks,
> Petteri.
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151208/b9262d3c/attachment-0001.html>