← Back to team overview

kicad-developers team mailing list archive

Re: Testing Tom’s integrated ngspice simulator on Mac OSX

 

Thanks!  This is good work! I'll start working with it on my test machine,
and it will be first in line after the cvpcb crash in the nightlies (which
is first in line after 4.0.3) :)

Adam Wolf

On Sun, Jul 31, 2016 at 3:56 PM, Johannes Maibaum <jmaibaum@xxxxxxxxx>
wrote:

> Hi Adam,
>
> I’ve attached a diff with my current changes to Tom’s ngspice branch on
> Github.  Unfortunately, I cannot guarantee that this is all that is
> needed.  As written in my last email, I obviously screwed up my app bundles
> so that I can’t start Eeschema to test.  It’s all still work in progress
> here.
>
> I don’t have a patch for wx, and I hope that none is needed.  The problem
> is that the wxCursor documentation doesn’t really say what to do on Mac
> OSX.  Their guideline for defining custom cursors only mentions Windows and
> Linux (and this is what Tom obviously implemented correctly).  But from
> reading through the available constructors, it seems to me that on OSX we
> should do the same as on Windows, i.e. constructing a wxImage from the
> cursor char arrays and handing that over to wxCursor.  And that is all,
> what my small patch does.
>
> So, yeah, if you are willing to set up a test build with my changes on
> your server that would be really nice, I think!  The only problem is that
> you will need to build and include libngspice.dylib into the package
> separately.  As I was not yet able to get to the point where Eeschema
> actually starts and tries to load libngspice.dylib, I cannot tell you what
> to do for this to work (I don’t even now, if my change in preparation for
> the .dylib extenstion in eeschema/sim/ngspice.cpp suffices for Eeschema to
> find the library if it’s installed)…
>
> What I can offer you, is my patch for Homebrew’s ngspice formula (the pull
> request is still pending) that builds and installs libngspice along with
> the usual executable [1].  As I have no idea about CMAKE and packaging in
> general, I don’t know what to do to include it into the app bundle.  I just
> wanted to try out Tom’s amazing work on OSX and was documenting my steps
> here.
>
>     Johannes
>
> [1]
> https://patch-diff.githubusercontent.com/raw/Homebrew/homebrew-core/pull/3367.diff
>
>
>
>
> > Am 31.07.2016 um 21:55 schrieb Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx
> >:
> >
> > If you make a branch with your changes, Johannes, I can test it here,
> and set up a build on the nightlies server for it.  It won't be super
> useful as right now there are some issues in the nightlies that will be
> resolved after 4.0.3 comes out (which will be soon!), but it will be nice
> to have.
> >
> > If you'd rather just give me a patch (or one for wx and one for kicad),
> that works too.
> >
> > Adam Wolf
> >
> > On Sun, Jul 31, 2016 at 2:51 PM, Johannes Maibaum <jmaibaum@xxxxxxxxx>
> wrote:
> > 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
> >
> >
> > _______________________________________________
> > 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
> >
>
>
>

Follow ups

References