kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 11/19/2014 1:28 PM, Bernhard Stegmaier wrote:
> 
> On 19.11.2014, at 18:59, Wayne Stambaugh <stambaughw@xxxxxxxxxxx
> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
> 
>> On 11/19/2014 12:38 PM, Bernhard Stegmaier wrote:
>>>
>>
>> cd build_folder
>> make clean                # clean any source files generated by CMake
> 
> I didn’t do the "make clean", ...
> 
>> rm -rf *
> 
> … but after that the folder is completely empty (I checked that more
> than once).
> 
>> cd src_path
>> rm -rf .downloads-by-cmake
>> rm -rf boost_root
> 
> So, all in all that should be pretty much what I do to get a clean build.
> That also always worked before.
> But, I can also try if a “make clean” does make any difference...

I always try to make sure that all of the source downloaded and
generated by CMake is gone.  I'm not 100% sure `make clean` gets rid of
all of it so I manually delete it myself.

> 
>>>
>>> It also was not a once issue… I made at least 3 or 4 builds (release and
>>> debug) this way and all of them consistently showed this problem.
>>>
>>> I checked the pcbnew binary and it seem to be correctly linked.
>>> The internal boost is built statically, whereas the external one is only
>>> built as dynamic libs.
>>> If I use external boost external libs are correctly linked/referenced.
>>> The broken pcbnew doesn’t reference any of the external dynamic libs, so
>>> I think it has been built against the internal static version.
>>>
>>> BTW: 
>>> eeschema starts up and also shows a version information with boost 1.56.
>>> So, I guess debugger is really right here.
>>
>> Eeschema doesn't use the boost context library so that is probably why
>> it doesn't crash.  My guess is your going to find that it crashes here:
>>
>> #if BOOST_VERSION >= 105600
>>    m_self = new boost::context::fcontext_t();
>>    *m_self = boost::context::make_fcontext( sp, m_stackSize, callerStub );
>> #else
>>    m_self = boost::context::make_fcontext( sp, m_stackSize, callerStub );
>> #endif
> 
> If you look at the screenshot of my first mail, the last call before it
> crashes is highlighted:
> 
> #if BOOST_VERSION >= 105600
> ==>  return boost::context::jump_fcontext(aOld, *aNew, aP,
> aPreserveFPU); <==
> 
> The *aNew seems to have changed from/to a pointer, that’s why it
> segfaults in jump_fcontext itself.
> 
>> If this is where the crash occurs, then FindBoost may be causing the
>> issue and we will have to sort it out.  It's easy to see if KiCad uses
>> the incorrect Boost version during the build how this would segfault.
> 
> Hmm?
> I didn’t get what you meant here...
> 
> 
> Regards,
> Bernhard