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 <lou...@yahoo.com> 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 <stambau...@verizon.net> wrote:
>>
>> 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
>
_______________________________________________
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
