On 11/19/2014 1:28 PM, Bernhard Stegmaier wrote: > > On 19.11.2014, at 18:59, Wayne Stambaugh <stambau...@verizon.net > <mailto:stambau...@verizon.net>> 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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp