kicad-developers team mailing list archive

[Johannes Maibaum <jmaibaum@xxxxxxxxx>]

Hi,

OK, I finally found the reason for the linking error from my previous mail.  Stupid me was already looking at eeschema/sim/simulate.cpp yesterday, where I found both SCH_EDIT_FRAME::CURSOR_PROBE and ::CURSOR_TUNE defined. What I overlooked was the conditional compilation macros (doh!).  In the current implementation they only get compiled on Windows and Linux, but not on OSX.

After a cursory (sorry, could’t resist) look over the wxCursor documentation [1] I can propose a solution.  The following change at least satisfies my the linker:


diff --git a/eeschema/sim/simulate.cpp b/eeschema/sim/simulate.cpp
index af15129..c67b570 100644
--- a/eeschema/sim/simulate.cpp
+++ b/eeschema/sim/simulate.cpp
@@ -93,7 +93,7 @@ static const unsigned char cursor_tune_mask[] = {
    0x3c, 0x00, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0x1f, 0x00, 0x00, 0x00,
    0x0e, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00 };
 
-#ifdef __WXMSW__
+#if defined(__WXMSW__) or defined(__WXMAC__)
 struct SIM_CURSORS_INIT
 {
 public:


I now can compile Tom’s branch successfully, yay!

However, I get instant segfaults in all Kicad applications now, and all fingers in the crashlog point towards the wxWidgets dynamic libraries, which obviously got not installed correctly into the App bundle, as I get tons of errors like this (it almost looks like for every wx class):


objc[6288]: Class wxNSAppController is implemented in both /Users/jm/build/kicad-dev/build/bin/kicad.app/Contents/Frameworks/libwx_osx_cocoau_core-3.0.0.2.0.dylib and /Users/jm/build/kicad-dev/build/bin/kicad.app/Contents/Frameworks/libwx_osx_cocoau_core-3.0.dylib. One of the two will be used. Which one is undefined.

Later in the crashlog there is this information (again one error for all wx classes used, it seems):


../wx-src/src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" failed in Register(): Class "wxAnimationBase" already in RTTI table - have you used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?


before it finally dies in a segfault.  I looked in the app bundle, and sure enough, there are both the -3.0.0.2.0.dylib and the -3.0.dylib libraries for libwx_baseu, libwx_osx_cocoa_adv and libwx_osx_cocoa_core.

It has been a while since I last compiled Kicad myself – thanks to Adam’s great work with the nightlies! – so it could just be that I screwed things up while patching/building wxWidgets.  I looked in three places: the (official?) OSX build instructions on kicad-pcb.org [2], Adams build-wx.sh from his bundle build script [3], and in the patches/ folder in the Kicad source tree and found three different sets of patches for wx on OSX.  For my current build I went with the patches listed in [2], but perhaps that was the wrong guess?  Could anyone of the OSX devs point me to the right patchset?  I think, I’ll try Adam’s next…

    Johannes

[1] http://docs.wxwidgets.org/3.0/classwx_cursor.html
[2] http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_compiling.html#build_osx
[3] http://bazaar.launchpad.net/~adamwolf/+junk/kicad-mac-packaging/view/head:/compile_wx.sh

> Am 30.07.2016 um 22:31 schrieb Johannes Maibaum <jmaibaum@xxxxxxxxx>:
> 
> Hi,
> 
> today, I was trying to get Tom’s ngspice branch to compile on OSX, but unfortunately without success.
> 
> Here is what I did so far:
> 
> 
> diff --git a/eeschema/sim/ngspice.cpp b/eeschema/sim/ngspice.cpp
> index 0c365c1..62679d5 100644
> --- a/eeschema/sim/ngspice.cpp
> +++ b/eeschema/sim/ngspice.cpp
> @@ -37,6 +37,8 @@ NGSPICE::NGSPICE()
> {
> #ifdef __WINDOWS__
>     m_dll = new wxDynamicLibrary( "libngspice-0.dll" );
> +#elif __APPLE__
> +    m_dll = new wxDynamicLibrary( "libngspice.dylib" );
> #else
>     m_dll = new wxDynamicLibrary( "libngspice.so" );
> #endif
> diff --git a/eeschema/sim/sim_plot_panel.cpp b/eeschema/sim/sim_plot_panel.cpp
> index 7dda993..1226da8 100644
> --- a/eeschema/sim/sim_plot_panel.cpp
> +++ b/eeschema/sim/sim_plot_panel.cpp
> @@ -332,8 +332,8 @@ bool CURSOR::Inside( wxPoint& aPoint )
>     if( !m_window )
>         return false;
> 
> -    return ( std::abs( aPoint.x - m_window->x2p( m_trace->x2s( m_coords.x ) ) ) <= DRAG_MARGIN )
> -        || ( std::abs( aPoint.y - m_window->y2p( m_trace->y2s( m_coords.y ) ) ) <= DRAG_MARGIN );
> +    return ( std::abs((double) aPoint.x - m_window->x2p( m_trace->x2s( m_coords.x ) ) ) <= DRAG_MARGIN )
> +        || ( std::abs((double) aPoint.y - m_window->y2p( m_trace->y2s( m_coords.y ) ) ) <= DRAG_MARGIN );
> }
> 
> 
> The change in eeschema/sim/ngspice.cpp was done in order to reflect the .dylib extension for dynamic libraries on OSX.
> 
> The change in eeschema/sim/sim_plot_panel.cpp was done as clang++ was complaining about ambiguous calls to `std::abs` in those two lines.  Casting aPoint.{x,y} to double resolved the ambiguity.
> 
> But now, linking _eeschema.kiface fails with the following error:
> 
> 
> […]
> [ 53%] Linking CXX shared module ../kicad/kicad.app/Contents/PlugIns/_eeschema.kiface
> Undefined symbols for architecture x86_64:
>  "SCH_EDIT_FRAME::CURSOR_TUNE", referenced from:
>      SCH_EDIT_FRAME::OnSelectTool(wxCommandEvent&) in schedit.cpp.o
>  "SCH_EDIT_FRAME::CURSOR_PROBE", referenced from:
>      SCH_EDIT_FRAME::OnSelectTool(wxCommandEvent&) in schedit.cpp.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> make[2]: *** [kicad/kicad.app/Contents/PlugIns/_eeschema.kiface] Error 1
> make[1]: *** [eeschema/CMakeFiles/eeschema_kiface.dir/all] Error 2
> make: *** [all] Error 2
> 
> 
> My cmake command line looked like this:
> 
> 
> cmake -DCMAKE_C_COMPILER=clang \
>      -DCMAKE_CXX_COMPILER=clang++ \
>      -DCMAKE_OSX_DEPLOYMENT_TARGET=10.11 \
>      -DwxWidgets_CONFIG_EXECUTABLE=../../../wx-bin/bin/wx-config \
>      -DKICAD_SPICE=ON \
>      -DCMAKE_INSTALL_PREFIX=../bin \
>      -DCMAKE_BUILD_TYPE=Release \
>      ../../
> 
> I.e. just the standard switches, plus the KICAD_SPICE option.
> 
> 
> This is where I got stuck for now.  Any ideas how to resolve this?
> 
>    Johannes