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

Bill Deegan bill at baddogconsulting.com
Tue Dec 8 14:44:19 EST 2015


On Tue, Dec 8, 2015 at 12:55 PM, William Blevins <wblevins001 at gmail.com>
wrote:

>
>
> 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
>

Perhaps a simple fix would be to change the SHOBJSUFFIX & OBJSUFFIX and/or
build your scons built objects into a different location.
Mixing and matching could cause issues especially where its not possible to
verify that both make and scons use the same compiler and compiler flags
(includinging preprocessor, include path,etc).


>
>
>>
>> ~$ 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.
>

As far as I understand, that's not the case.  It does (typically, though
varies by compiler/platform) use a different extension for shared vs static
objects..
Platform/posix.py:    env['OBJSUFFIX']      = '.o'
Tool/c++.py:    env['SHOBJSUFFIX'] = '.os'
Tool/c++.py:    env['OBJSUFFIX'] = '.o'
Tool/cc.py:    env['SHOBJSUFFIX'] = '.os'




>
>
>>
>> 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.
>> _______________________________________________
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151208/40413f42/attachment.html>


More information about the Scons-users mailing list