Building OpenCPN on OSX-10.10 (Yosemite)

[fogmachine]

I was able to build the current OpenCPN and weatherfax_pi dev branches from scratch, but as a relative n00b to building on Macs and the last 20 years of Open Source tooling this was harder than I thought it would be. Maybe these notes will help others and help improve the Mac documentation.

Notes on building OpenCPN on OSX-10.10 (Yosemite) with Xcode-6.3.1:

• OpenCPN dev environment:
  
  • XCode & OSX-10.7 SDK
    
    OpenCPN needs two of Apple's developer packages - the Xcode IDE and the older SDK for OSX-10.7 (Lion). Both are available for free but require (free) registration with Apple's developer program at developer.apple.com.
    
    Xcode is available from the App store and installs into /Applications/Xcode.app.
    
    OpenCPN is built with the OSX-10.7 (Lion) SDK and must be extracted from Xcode-4.6.3:
    
    • Download Xcode-4.6.3 from
      
      https://developer.apple.com/downloads
      or
      https://adcdownload.apple.com/Develo...630916281a.dmg
      
    • Extract the SDK and add it to Xcode:
      
      hdiutil attach ~/Downloads/xcode4630916281a.dmg
      sudo sh -c "(cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs ; mkdir MacOSX10.7.sdk ; chown ${USER} MacOSX10.7.sdk)"
      (cd /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs ; tar cf - MacOSX10.7.sdk) | (cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs; tar xf -)
      hdiutil detach /Volumes/Xcode
      
• OpenCPN dependencies:
  
  • TinyXML:
    
    I had tinyxml installed from MacPorts, but it was incompatible with OpenCPN. I uninstalled with:
    
    sudo ports uninstall tinyxml
    
  • Packages:
    
    OpenCPN requires "Packages" to build install bundles (currently version 1.1.2):
    • Download from
      http://s.sudre.free.fr/Software/Packages/about.html
      and install.
  • wxWidgets:
    
    OpenCPN uses wxWidgets-3.0.2 for multi-platform GUI support.
    
    • Download from http://sourceforge.net/projects/wxwi...r.bz2/download
    • Build wxWidgets
      
      mkdir build-release
      cd build-release
      ../configure --enable-unicode --with-osx-cocoa --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/ --with-macosx-version-min=10.7 --enable-aui --disable-debug --enable-opengl --without-liblzm
      make
      sudo make install
      
    Note: wxWidgets is in active development; OpenCPN may need source changes to work with the next "3.1.0" release. wxWindows-3.0.2 requires a minor source change to compile with OSX-10.10 interfaces.
• Building OpenCPN
  
  • Get source code (currently v4.1.427)
    
    git clone https://github.com/OpenCPN/OpenCPN
    
  • Build from command line:
    
    cd OpenCPN
    export MACOSX_DEPLOYMENT_TARGET=10.7
    mkdir build
    cd build
    cmake ..
    make
    make package
    sudo make install
    (This puts OpenCPN.app into /usr/local)
    
    I had to remove a pile of wx libraries that were installed with OpenCPN and conflicted with /usr/local/lib. I'm sure this is wrong - probably a conflict with the local build of wxWidgets.
    
    sudo rm /usr/local/bin/OpenCPN.app/Contents/MacOS/wx*dylib
    
    
  • Build using Xcode
    
    cd OpenCPN
    export MACOSX_DEPLOYMENT_TARGET=10.7
    mkdir xbuild
    cd xbuild
    cmake -G Xcode ../
    
    With Xcode File-->Open the OpenCPN/xcode/OpenCPN.xcodeproj project
    Build the OpenCPN & Package targets rather than the default "ALL_BUILD" target.
    
    (How to install from Xcode?)
• Weatherfax plugin dependencies
  
  • weatherfax_pi ships with its own portaudio binary; the build system was confused because I'd installed the MacPorts version into /opt/local. I removed it with:
    
    sudo port uninstall portaudio
    
  • Get the weatherfax portaudio package from SourceForge.
    http://sourceforge.net/projects/open...0.pkg/download
• Building weatherfax_pi from dev branch
  • Get source code
    
    git clone https://github.com/seandepagnier/weatherfax_pi
    
  • Build from command line
    
    cd weatherfax_pi
    export MACOSX_DEPLOYMENT_TARGET=10.7
    mkdir weatherfax_pi/build
    cd weatherfax_pi/build
    cmake ..
    cmake --build .
    make create-pkg
    
    Double-click on the package in weatherfax_pi/build/WeatherFax-Plugin_1.3.pkg
    
    This installs into /Applications/OpenCPN.app - I made a symlink to /usr/local/bin/OpenCPN.app
    
    (How to build and debug from Xcode?)

[CarCode]

Originally Posted by fogmachine

(How to build and debug from Xcode?)

You may find an example here:
https://github.com/CarCode/Cocoa-OCPN.git
But this *.xcodeproj found there must heavily changed to your environment.
I have a fully different concept using not cmake but only Xcode, no standalone plugins but forcing plugins using one single code source only (e.g. for tinyxml, Json, wxCurl etc.).

Gerhard

[rgleason]

Dear FogMachine.
Between you and Peter [Ptulp], Caesar Schinas -menus etc, Gerhard [Carcode] the Mac OS has made great strides. Not many have compiled under Mac, so your experience is invaluable. Would you mind taking a closer look at the Developer's Manual for Compiling Mac

Compiling - Mac OS X | Official OpenCPN Homepage

You can register here User account | Official OpenCPN Homepage if you have not done so, and are then able to make edits and improvements. I know it will be much appreciated by other Mac users, as this group is getting larger and more active. Peter is a good resource for Mac. Thank you.

[ptulp]

Originally Posted by fogmachine

• Weatherfax plugin dependencies
  • weatherfax_pi ships with its own portaudio binary; the build system was confused because I'd installed the MacPorts version into /opt/local. I removed it with:
    
    sudo port uninstall portaudio
    
  • Get the weatherfax portaudio package from SourceForge.
    Download opencpnplugins from SourceForge.net

I think the link above is not correct, it should be:
Download opencpnplugins from SourceForge.net

Peter

[fogmachine]

Oops! Peter is correct - the url for the pre-bundled portsaudio library is http://sourceforge.net/projects/open...s.zip/download. (Fooled by the automagic link converter again.)

[bdbcat]

fogmachine....

Just so we are clear...

Do you find that the wxWidgets libraries bundled with the OCPN4.0.0 release are not compatible with your Yosemite build environment?

Or, said another way, is it required that you build wxWidgets locally on your machine to build OCPN? It should not be.

Contrast to linux, where the appropriate wxwidgets-dev package brings the wx include tree, and that is all that is required to build O from source.

All by way of learning more about OSx.

Dave

[fogmachine]

Originally Posted by bdbcat

fogmachine....

Just so we are clear...

Do you find that the wxWidgets libraries bundled with the OCPN4.0.0 release are not compatible with your Yosemite build environment?

Or, said another way, is it required that you build wxWidgets locally on your machine to build OCPN? It should not be.

Contrast to linux, where the appropriate wxwidgets-dev package brings the wx include tree, and that is all that is required to build O from source.

All by way of learning more about OSx.

Dave

Hmmm... well, if you put it that way...

My intuition is that wxwidgets-dev on Linux works in a way that "ports install wxwidgets" (or the brew equivalent) should on OSX but doesn't due to recent interface/SDK changes on the OSX side, hence the need to install from source. AFAIK:

• The OpenCPN-4.0.0 release package works just fine, including the bundled wxWidgets. This is the most important point since few users wish to develop.
• There are some complexities with wxWidgets on OSX:
  • OpenCPN is built to with OSX-10.7 (Lion) compatibility which is from 2011 while Apple is currently shipping OSX-10.10 (Yosemite) - plenty of time for drift.
  • Building wxWidgets-3.0.2 on OSX-10.10 works just fine as long as you set it up for compatibility with OSX-10.7. This is easy to forget/overlook.
  • (Digression) wxWidgets-3.0.2 does not compile on the current OSX-10.10 without a small modification. This was confusing and lead into a cul-de-sac.
  • (Digression) The upcoming wxWidgets-3.1.0 fixes the OSX-10.10 issues but isn't compatible with OpenCPN (in hopefully small ways). If and when OpenCPN adopts the new version testing across all the platforms will be important.
• wxWidgets "make install" puts the dylibs into /usr/local/lib; the OpenCPN Mac package "make install" puts a copy into /usr/local/bin/OpenCPN.app/Contents/MacOS. When I run OpenCPN from the command line with /usr/local/bin/OpenCPN.app/Contents/MacOS/OpenCPN there is a spew of conflicting library messages and the application fails. I got it to work by removing the copies in the OpenCPN dir. I don't know why it didn't just use the first set of libraries on the path which is the behavior I've seen for the past 35 years.
• The current Mac documentation doesn't actually say how to install/run/debug OpenCPN or its plugins, so my knowledge is via trial and error, getting hints from Peter, etc. I'm sure I'm doing things "wrong" since I'm not a seasoned Mac developer. This is not a knock on the OpenCPN developers, just a place that could be improved.

As much as I love Linux on servers, it doesn't seem to have much place on the laptop or desktop machines in my life.

lance

[CarCode]

Originally Posted by fogmachine

• wxWidgets "make install" puts the dylibs into /usr/local/lib; the OpenCPN Mac package "make install" puts a copy into /usr/local/bin/OpenCPN.app/Contents/MacOS. When I run OpenCPN from the command line with /usr/local/bin/OpenCPN.app/Contents/MacOS/OpenCPN there is a spew of conflicting library messages and the application fails. I got it to work by removing the copies in the OpenCPN dir. I don't know why it didn't just use the first set of libraries on the path which is the behavior I've seen for the past 35 years.

You guys should read a little bit the documentations from Apple. There are plenty docs beginning from style guides to Xcode docs and SDK docs all for free from Apple. E.g. once a dynamic lib was build it is needed to use the install_name_tool command for example:

install_name_tool -change /usr/local/lib/libwx_baseu-3.1.0.0.0.dylib @executable_path/../Frameworks/libwx_baseu-3.1.dylib Frameworks/libwx_baseu_net-3.1.dylib

So the dylib can be placed in /Applications/OpenCPN/Contents/Frameworks/ where it should be.

• The current Mac documentation doesn't actually say how to install/run/debug OpenCPN or its plugins, so my knowledge is via trial and error, getting hints from Peter, etc. I'm sure I'm doing things "wrong" since I'm not a seasoned Mac developer. This is not a knock on the OpenCPN developers, just a place that could be improved.

Mac OS X is neither Linux nor Windows and it seems the Mac docs at opencpn.org are done by Linux or Windows people. Xcode uses the LLVM compiler which seems to be more powerfull than Linux or Windows compilers although the focus of Xcode is more on Objectiv-C and Swift than C++. The tools of Xcode such as the GDB and LLDB debuggers or the Instruments are very helpfull.

Gerhard

[fogmachine]

Originally Posted by CarCode

[/LIST]You guys should read a little bit the documentations from Apple. There are plenty docs beginning from style guides to Xcode docs and SDK docs all for free from Apple. E.g. once a dynamic lib was build it is needed to use the install_name_tool command for example:

install_name_tool -change /usr/local/lib/libwx_baseu-3.1.0.0.0.dylib @executable_path/../Frameworks/libwx_baseu-3.1.dylib Frameworks/libwx_baseu_net-3.1.dylib

So the dylib can be placed in /Applications/OpenCPN/Contents/Frameworks/ where it should be.

Gerhard

Gerhard, I'm spending quite a few hours a day reading various manuals, install guides, wikis, blogs, etc - it's a slow process. Could you post some pointers to the documentation you find most useful to help guide me and others? I think we agree that the OpenCPN docs for OSX can be improved.

[CarCode]

Originally Posted by fogmachine

Gerhard, I'm spending quite a few hours a day reading various manuals, install guides, wikis, blogs, etc - it's a slow process. Could you post some pointers to the documentation you find most useful to help guide me and others? I think we agree that the OpenCPN docs for OSX can be improved.

For sure my brain also is too small to keep all the megabytes of docs in it and I'm neither a professionell Apple developper whos everyday job is the handling of such stuff nor I'm young enough to strech my brain. However Mac OS X has a nice help system which helps to find the needed informations just in time when needed. E.g. go to the help menu in Xcode where you see "Documentation and API Reference" which opens the SDK docs and the Xcode docs. The search function is remarkable fast. If it's a first time download of Xcode it might be needed to go to settings/download first for getting the latest docs (about 1 GB).

Gerhard

[povl]

I've just tried building the latest version of OpenCPN on my Mac running Yosemite, and have found a bug introduced by a recent change to chart1.cpp and CMakeLists.txt. That change introduces a new preprocessor variable, "OCPN_HAVE_X11". If X11 is present on a Mac (as it is on my system), the variable is set - and the compilation of chart1.cpp fails. I've changed line 1369 of CMakeLists.txt from "IF (X11_FOUND)" to "IF(X11_FOUND AND NOT APPLE)". This should work - except if anyone is trying to compile OpenCPN for X11 on a Mac...

Thanks for everyone for your work on OpenCPN and for including/developing Mac support!

[AuroraGH]

I've checked out the latest sources and taken a crack at building.

Thanks to fogmachine for the instructions on getting osx 7 build target set up (why are we stuck on that?).

I dislike macports a lot and use homebrew. brew install wxwidgets does mostly the right thing. The xcode project creator works well enough. However I hit a problem in wx/strvararg.h

It seems the HAVE_TYPE_TRAITS and HAVE_TR1_TYPE_TRAITS flags are set backwards. I worked around this by modifying the wx/strvararg.h on line 25 as


#undef HAVE_TYPE_TRAITS
#define HAVE_TR1_TYPE_TRAITS 1

and lots of stuff compiles!

Until I get to S57ENC library where I get all kinds of strange errors starting on line 57

"void CPL_DLL CPLError(CPLErr eErrClass, int err_no, const char *fmt, ...) CPL_PRINT_FUNC_FORMAT (3, 4);" - Expected function body after function declarator

which implies to me that there is a macro set wrong somewhere but I can't guess what so far. Every other module builds fine.

[nohal]

AuroraGH...
Any reason not to simply follow the official build instructions from Compiling - Mac OS X | Official OpenCPN Homepage (If you want to build the DMG, they already count with https://github.com/OpenCPN/OpenCPN/pull/430 being merged)?
And any reason not to "be stuck" with OS X 10.7 as the deployment target? Users actually seem to be more interested in supporting 10.6 than abandoning even 10.7 as far as I can tell.

Pavel

[AuroraGH]

Originally Posted by nohal

AuroraGH...
Any reason not to simply follow the official build instructions from Compiling - Mac OS X | Official OpenCPN Homepage (If you want to build the DMG, they already count with https://github.com/OpenCPN/OpenCPN/pull/430 being merged)?
And any reason not to "be stuck" with OS X 10.7 as the deployment target? Users actually seem to be more interested in supporting 10.6 than abandoning even 10.7 as far as I can tell.

1) It doesn't work? and 2) an iOS port would be cool for iPads?

I started over - except rather than build wxwidgets from source I installed via brew. Still fails to build the same way.

And here's the thing. I don't care if the command line build works or some other build works - I want an XCode based development environment so I can do work on it like an iOS or Cocoa port - assuming I can divorce the core from wxwidgets cleanly.

[nohal]

Originally Posted by AuroraGH

1) It doesn't work? and

Doesn't work what? I'm building OpenCPN all the time following it and see no failure.

2) an iOS port would be cool for iPads?

It sure would, it is a shame that it is not possible to get any GPL licensed software on it and as such any development effort in this direction is a waste of time.

I started over - except rather than build wxwidgets from source I installed via brew. Still fails to build the same way.

Don't use homebrew or macports, follow the build instructions and you will save yourself the frustration.

And here's the thing. I don't care if the command line build works or some other build works - I want an XCode based development environment so I can do work on it like an iOS or Cocoa port - assuming I can divorce the core from wxwidgets cleanly.

I don't understand you - cmake generates a complete Xcode project for you, which you of course edit, build, debug, profile and run from Xcode GUI.

Pavel