kicad-developers team mailing list archive

[Jean-Paul Louis <louijp@xxxxxxxxx>]

I forgot to show the kicad Info

Application: kicad
Version: (2014-11-19 BZR 5293)-product Release build
wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8)
Platform: Mac OS X (Darwin 14.0.0 x86_64), 64 bit, Little endian, wxMac
Boost version: 1.54.0
        USE_WX_GRAPHICS_CONTEXT=OFF
        USE_WX_OVERLAY=ON
        KICAD_SCRIPTING=OFF
        KICAD_SCRIPTING_MODULES=OFF
        KICAD_SCRIPTING_WXPYTHON=OFF
        USE_FP_LIB_TABLE=HARD_CODED_ON
        BUILD_GITHUB_PLUGIN=ON

Jean-Paul
AC9GH



> On Nov 20, 2014, at 2:29 PM, Jean-Paul Louis <louijp@xxxxxxxxx> wrote:
> 
> To get a baseline, I just build KiCad from scratch.
> I just upgraded to OS X Yosemite, refreshed all my MacPorts for the dev tools, 
> and I am using Xcode 6.1,
> clang 6.1.1,
> Cmake 3.0.2,
> make 3.81,
> wxwidgets 3.0.2.
> 
> Jean-Pauls-MacBook-Pro-3:Soft_Dev jean-paullouis$ cmake --version
> cmake version 3.0.2
> 
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
> Jean-Pauls-MacBook-Pro-3:Soft_Dev jean-paullouis$ make --version
> GNU Make 3.81
> Copyright (C) 2006  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> This program built for i386-apple-darwin11.3.0
> 
> 
> 
> This first build is using the boost 1.54 patched by KiCad.
> It finished without error, and both eeschema and pcbnew are starting properly when started in that order. Starting pcbnew, then eeschema still brings the ugly red background in eeschema.
> 
> I have not yet patched wxwidgets with Adam’s patch for Yosemite. I will do that next.
> 
> Then I will try to use the stock Boost 1.57, and will let you know what I find.
> 
> Regards,
> Jean-Paul
> AC9GH
> 
> 
> 
> 
> 
>> On Nov 19, 2014, at 1:48 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>