Trouble building 3.2 on Mac

[jasenj1]

I saw that 3.2 is not yet available for the Mac as an app, so I figured I'd try compiling it - since I'm a real live software developer (but mostly Java web apps).

I started with the instructions found here. But neither of the two sets provided seemed exactly right, so I tried a couple of blends between the two.

I'm running OS X 10.7 with XCode 4.6 on a year old MacBook Pro. I also use MacPorts for all my UNIX libraries and apps. MacPorts has several versions of wxWidgets available - I tried 2.8, 2.9 and 3.0 (really 2.9) variants.

I used the command "cmake -G Xcode ../" to get things rolling, and that seemed to work fine. However, when I tried to compile with XCode I get ~200 errors.

I get a big stack of warnings that look like this:
ld: warning: ignoring file /Users/xxx/Documents/git/OpenCPN/build/Debug/libNMEA0183.a, file was built for archive which is not the architecture being linked (i386): /Users/xxx/Documents/git/OpenCPN/build/Debug/libNMEA0183.a
ld: warning: ignoring file /Users/xxx/Documents/git/OpenCPN/build/Debug/libGARMINHOST.a, file was built for archive which is not the architecture being linked (i386): /Users/xxx/Documents/git/OpenCPN/build/Debug/libGARMINHOST.a
ld: warning: ignoring file /opt/local/lib/libgobject-2.0.dylib, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libgobject-2.0.dylib
ld: warning: ignoring file /opt/local/lib/libglib-2.0.dylib, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libglib-2.0.dylib
ld: warning: ignoring file /Users/xxx/Documents/git/OpenCPN/build/Debug/libS57ENC.a, file was built for archive which is not the architecture being linked (i386): /Users/xxx/Documents/git/OpenCPN/build/Debug/libS57ENC.a

And then a big stack of errors that start with:
Undefined symbols for architecture i386:

I believe this is telling me the libraries OpenCPN needs were compiled with an unexpected target architecture. Unfortunately, I have no idea how to fix this, or how deep this architecture issue goes - do I need to instruct MacPorts to build all its libraries with a certain architecture? If so, how would I do that?

The Lion instructions seem to ignore XCode entirely but rely on a version of OpenCPN source from someone else's git repository that is about a year old, so I don't think I want to use that.

Any help would be appreciated.

- Jasen.

[jasenj1]

Well, a sure way to figure out a problem is to ask a question.

With a little more Googling, I found that MacPorts' wxWidgets-devel can be installed as 32 and 64 bit (universal). The command is "sudo port install wxWidgets-devel +universal". Having done that, in XCode I had to set the target architecture to 32-bit (i386) and build only that architecture. With all of that set up, the app built - I have a nice OpenCPN.app.

Unfortunately, the app now crashes with wxWidgets complaints after I add a chart directory. But it is progress!

- Jasen.

[jasenj1]

I was also able to build the app using "cmake ../" and then just "make" - no Xcode GUI required.

The wxWidgets crash goes away if I check "Use Accelerated Graphics (OpenGL)". If I uncheck it, OpenCPN crashes when trying to render charts.

- Jasen.

[jasenj1]

Unfortunately, performance is insanely slow. Any scrolling of charts is met with LONG spinning beach balls.

I guess I'll leave building OpenCPN to the professionals and settle for using 3.1 for now.

- Jasen.

[sbfreddie]

Originally Posted by jasenj1

Unfortunately, performance is insanely slow. Any scrolling of charts is met with LONG spinning beach balls.

I guess I'll leave building OpenCPN to the professionals and settle for using 3.1 for now.

- Jasen.

Jasen:
Hello, I'm Freddie and I have been working on these issues for a long time. The 32 bit version using wxWidgets 2.8.x is terribly slow and buggy.
I have been using wxWidgets 2.9.4 for a while now and OpenCPN is very snappy, more like you would expect it to be on a modern Mac.
If you have all the prerequisites built for 64 bit, it will build using either Xcode or on the Command Line.
You just have to give Cmake the correct commands.

When compiling do not use clang, it does not like much of the code. Use the alternative compiler instead.
He is an example of my invocation at the command line for Xcode:
cmake -DCMAKE_OSX_64=ON -DCMAKE_OSX_DEPLOYMENT_TARGET=10.6 -DPREFIX=/Users/freddie/Desktop/OpenCPN3.2/buildmac -DGETTEXT_MSGFMT_EXECUTABLE=/usr/local/Cellar/gettext/0.18.1.1/bin/msgfmt -DGETTEXT_MSGMERGE_EXECUTABLE=/usr/local/Cellar/gettext/0.18.1.1/bin/msgmerge -DCMAKE_C_COMPILER=/usr/bin/gcc -DCMAKE_CXX_COMPILER=/usr/bin/g++ -G Xcode ../

And here is an example of my invocation at the command line for a Command Line build:
cmake -DCMAKE_OSX_64=ON -DCMAKE_OSX_DEPLOYMENT_TARGET=10.6 -DPREFIX=/Users/freddie/Desktop/OpenCPN3.2/buildmac -DGETTEXT_MSGFMT_EXECUTABLE=/usr/local/Cellar/gettext/0.18.1.1/bin/msgfmt -DGETTEXT_MSGMERGE_EXECUTABLE=/usr/local/Cellar/gettext/0.18.1.1/bin/msgmerge -DCMAKE_C_COMPILER=/usr/bin/gcc -DCMAKE_CXX_COMPILER=/usr/bin/g++ ..

If you need added help just help

Thanks,
Freddie

[bdbcat]

jasenj1...

Thanks for your report.

Clearly we have some trouble building the 32 bit version of OCPN on post-Snow-Leopard Mac OS. We'll come back to that.

But I want to address your point about performance on the Mac.
For reference, have you tried any of the latest Mac Betas available on the opencpn.org site? 3.1.1319 is actually very close to the 3.2.0 release in terms of performance and functionality. It runs fairly snappily on my Snow Leopard Mac Mini, certainly equal to the performance seen on Win7. Entirely usable.

I'm thinking that your performance observation results from the somehow broken build on post-SnowLeopard. But maybe not...

Anyone else have relevant observations regarding performance of the 3.1 Beta series on any Mac platforms?

btw, the official 3.2 release for Mac is uploading as we speak, over a very slow connection. Should be up soon, probably tomorrow.

Thanks
Dave

[jasenj1]

Originally Posted by bdbcat

But I want to address your point about performance on the Mac.
For reference, have you tried any of the latest Mac Betas available on the opencpn.org site? 3.1.1319 is actually very close to the 3.2.0 release in terms of performance and functionality. It runs fairly snappily on my Snow Leopard Mac Mini, certainly equal to the performance seen on Win7. Entirely usable.

I am happily using the 3.1 app available for download from the OCPN site. It is quite usable.

I'm thinking that your performance observation results from the somehow broken build on post-SnowLeopard. But maybe not...

Based on Freddie's post, it sounds like there's a lot of tweaking that can be done to the build. I'll give his suggestions a try and see what happens.

btw, the official 3.2 release for Mac is uploading as we speak, over a very slow connection. Should be up soon, probably tomorrow.

Great!

- Jasen.

[jasenj1]

Originally Posted by sbfreddie

Jasen:
Hello, I'm Freddie and I have been working on these issues for a long time. The 32 bit version using wxWidgets 2.8.x is terribly slow and buggy.
I have been using wxWidgets 2.9.4 for a while now and OpenCPN is very snappy, more like you would expect it to be on a modern Mac.

I built with what MacPorts claims is wxWidgets 2.9.4. For some reason the port file is named wxWidgets30. Sounds like the 32 bit version of 2.9.4 has problems, too.

If you have all the prerequisites built for 64 bit, it will build using either Xcode or on the Command Line.
You just have to give Cmake the correct commands.

I'll give it a try. But since 3.2 is being uploaded, there may be no need. Documenting the correct way to build OCPN may have value, though.

- Jasen.

[colemj]

Originally Posted by bdbcat

Anyone else have relevant observations regarding performance of the 3.1 Beta series on any Mac platforms?

The 3.1x beta works fine on my new macbook pro running mountain lion 10.8.2. At least as well as 3.2 runs on my winxp netbook. I can regularly crash it (and the mac) when messing around setting up data ports, but that may be the serial-usb adapter driver fault.

Mark

[jasenj1]

I just pulled down 3.2 from SourceForge. It works great.

I think how wxWidgets is built is very important. My problems seem to be related to wxWidgets. I'd like to see the configure and build options used for wxWidgets.

- Jasen.

[vortexfive]

Hi

I've built OpenCPN 3.2 on my Mac using wxWidgets30 from macports too and I also experience very slow response. The binary I downloaded from Sourceforge works well.

I use OS X 10.8.2 and have tried builing OpenCPN using

>cmake -DCMAKE_OSX_64=ON -DCMAKE_C_COMPILER=/usr/bin/gcc -DCMAKE_CXX_COMPILER=/usr/bin/g++ ../
,
>cmake -DCMAKE_OSX_64=ON -G Xcode ../
and
>cmake ../

I profiled OpenCPN while doing unit_test_1 and it seems that almost 100% of the time is spent in MyFrame::OnFrameTimer1 (with the CPU running at 100% too).

I'ld like to help solve this problem, so all hints are welcome.
(I'll be submitting a small non-related merge request on Github soon too.)

[vortexfive]

Could you post the build settings you used for wxWidgets?
I used wxWidgets30 from macports which compilex wxWidgets 2.9.4 with the following configure options
--with-libjpeg --with-libtiff --with-libpng --with-zlib --with-opengl --with-cocoa --with-sdl --disable-sdltest --enable-unicode --enable-display --enable-xrc --enable-debug

This is part of the profiling graph recorded while OpenCPN was running at 100% cpu (for a long time).

[bdbcat]

vortexfive....

Your wxWidgets build options look generic, and should be fine.

I will need to wait until I have better internet access to try the wx 2.9/3.0 build. Also, I am running Show Leopard, so the 64 bit stuff may not work out the same as your 10.8 environment. Opinions?

Regarding the profile trace, it looks as though it is stuck in wxMask:Create(), although I don't really know how to read the output of this profiler. Maybe I need a slightly bigger snapshot. What is your take on this?

Thanks
Dave

[vortexfive]

Hi

Yes, the Snow Leopard/Mountain Lion may cause the problem.
A few posts back sbfreddie reported being able to build OpenCPN using wxWidgets 2.9.4 for 64-bit. The only difference I see is that he targed OS X 10.6. I'll try that in the future, but I need to install the SDK for 10.6 first.

The profile trace does indeed show that wxMask::Create() is the function that takes way too much time, I think. The trace was made with Instruments (part of the new Xcode). I can send you the file if you want.

I found that disabling quilting makes my build of OpenCPN useable, although there are still some crashes that don't occur with the version I downloaded from Sourceforge.
I'ld really like to be able to make my own fully working builds, so that I can try to help testing and debugging a bit here and there.

[jasenj1]

Originally Posted by vortexfive

I've built OpenCPN 3.2 on my Mac using wxWidgets30 from macports too and I also experience very slow response.

Glad to see another MacPorts user. MacPorts certainly makes library and dependency management easier, but my fear is it hides compile and build settings in ways that may be hard to diagnose.

My builds of OpenCPN crash with an error from wxWidgets complaining about some argument type not being correct. (Don't have that machine in front of me at the moment.) Tracing it through, it looks like a crash that gets generated if debug mode is turned on, and the error should be ignored if debug mode is off. I'm pretty sure I'm building with debug off, but the crash would indicate otherwise.

With my builds, I'm targeting 10.7, FWIW. If the official builds are targeting 10.6, that's another variable in the mix.

- Jasen.