Trying to Build Mac Version

[AuroraGH]

Originally Posted by nohal

AuroraGH...
On Windows and Linux, there are no complaints from wxWidgets at all, so as far as I can tell it's not normal. What are they about?
Thanks for the patch, will have a look at it later today.

Pavel

../src/mac/carbon/bitmap.cpp(242): assert "m_hBitmap failed in Create(): Unable to create CGBitmapContext context

the console reports

<Error>: CGBitmapContextCreate: invalid data bytes/row: should be at least 4 for 8 integer bits/component, 3 components, kCGImageAlphaNoneSkipFirst.

other errors cascade from there....

../src/mac/carbon/bitmap.cpp(1169): assert "ret.OK()" failed in GetSubBitmap(): GetSubBitmap error

../src/mac/carbon/bitmap.cpp(1139): assert "Ok()" failed in BeginRawAccess(): invalid bitmap

../src/mac/carbon/bitmap.cpp(1177): assert "sourcedata != _null && (destdata != _null)" failed in GetSubBitmap().

etc......

[CarinaPDX]

I assume that you are building using ALL carbon 32-bit code? This includes the MacPort installs (unless you change your defaults to universal), which will require setting flags for each install. Until WxWidgets releases v3 the support for cocoa in 2.9.3 is still in testing, and probably won't work. And even the carbon support is a little flaky.

Beyond that, I can't help much. Back a year or two ago I got the build working by outputting cmake to xcode, but that was the limit of my effort. The proper next step would have been to get the build completed in cmake but I don't think that was pursued. Since I haven't touched programming since my FORTRAN and BASIC days in the 70's this is all a bit over my head.

Good Luck.

Greg

[bdbcat]

AuroraGH....

Thanks for working on the Mac build. Its good to have another Mac developer working from the sourceforge git repo, and hopefully reproducing my work in a repeatable way. I think that this is the first step in making releasable progress for Mac.

As you may have surmised, we are currently only supporting 32 bit OCPN builds on Mac. 64 bit seems to require wxWidgets 2.9, which we are not ready to adopt. We don't want to be on the bleeding edge of wxWidgets development. I expect that we will move the entire project to wxWidgets 3.0 as soon as that version appears in any released way, maybe this year???

Here is how I build 2.6 on Leopard:

0. Get the dependencies specified in the OCPN wiki article
1. git the full OCPN source tree from sourceforge git repo.
2. in the opencpn directory, $mkdir build_carbon
3. cd build_carbon
4. cmake -DPREFIX=/Users/dsr/tmp ..
5. $make
6. $make install
7. $make create-dmg

So, you see that I use standard cmake/gcc toochain. All this works for me on my x86 Hackintosh. No build errors, no runtime asserts.

I have not tried to cmake an xcode project from the current tree, so don't know if it works or not. This would surely be a good goal to work toward for increasing Mac developer involvement.

I'd like to incorporate your current modifications into the next Beta release. Do you have a patch, or a git repo to pull from?

Any other progress to report?

Thanks again, and welcome aboard
Dave

[AuroraGH]

I submitted a pull request for some of the build script tweaks I made and I think Pavel picked them up.

I'm NOT building 32 bit carbon these days - well, I did build one and it gave me lots of errors - but carbon is dead. It has been dead since 2000 and the writing was on the wall then.

I want to build a fat 32/64 binary and I'd like to take a crack at an iOS version but I'm finding wxW pollution throughout the interfaces and it is making it difficult to separate the UI from the core.

I've kind of shelved my efforts for the moment because, among other things, I need to write an autopilot and I've got some system/sensor integration issues and I can pretty well use MacENC and iNavX for now and I want wxWidgets got get their Mac build issues sorted out. They're still trying to configure builds for 10.4 and that SDK isn't even available anymore so they fail.

Meanwhile I've written an iPhone app that broadcasts compass/gps/motion telemetry in NMEA over UDP on WiFi and this combined with a WiFi only iPad is looking pretty slick as a cheap and cheerful plotter.

[CarinaPDX]

AuroraGH- I completely sympathize with your desire to avoid carbon. Unfortunately, as Dave pointed out, cocoa support in wxwidgets won't be stable until the v3 release, and the timing for that is very approximately this summer. I also sympathize with Dave's desire to avoid the bleeding edge of wx; certainly without a committed Mac developer there is no incentive to get OCPN working on wx 2.9.3 as it seems the main reason for 2.9.x is to develop wx for cocoa on the Mac platform, and it is still in testing so that would be a lot of work for marginal returns. So it sounds like patience is called for. I hope you will get involved in the future when wx v3 is out - we really need help from people like you who know the Mac. But agreed, no point investing in carbon at this point. Thanks for helping. Greg

[CarinaPDX]

Dave-

I thought I would try your recipe above on my Core 2 Duo Snow Leopard MacBook Pro.

Using MacPorts I installed WxWidgets (2.8.12), Glib2, GTK2, tinyxml, and gpsd (2.95). Step 4 wouldn't work with gpsd (3.4), which I suspect is cocoa only.

The only problem left with step 4 is this:

"CMake Warning at plugins/grib_pi/CMakeLists.txt:73 (ADD_LIBRARY):
Cannot generate a safe linker search path for target grib_pi because files
in some directories may conflict with libraries in implicit directories:

link library [libz.dylib] in /usr/lib may be hidden by files in:
/opt/local/lib

Some of these libraries may not be found correctly."

Step 5 (make) blows up badly. Apparently the GCC 64-bit compiler is being invoked (which would be the default on my system). Is there a way to explicitly specify use of the 32-bit compiler to override?

I'm happy to try to get a dmg out of this, including snow leopard support. I have the 10.4, 10.4u, 10.5, and 10.6 SDKs, so with the right switches set I could build for them (again, something to add to the build instructions - something I don't know how to do with cmake). It would always be possible to use cmake to export to xcode and build there but it seems to me to be better to first get the more standard approach in your recipe working.

Thanks for the help (and all you have done!). As noted above, my skills are limited but will do my best if I can help.

Greg

[bdbcat]

Greg....

Thanks for trying the dmg build on 64 bit Snow Leopard. I agree with you. This is a valuable step in moving this Mac support of OCPN 2.6 forward.

I think you can safely ignore the CMake warning in step 4. Worst that would happen is that the GRIB PlugIn would not make it into the dmg, for now.

Main problem is 64 bit compiler. Obviously we need a switch in the CMakeLists.txt to tell the compiler to be 32 bits. I suspect google can help here
Try this link:
Cocoa with Love: Building for earlier OS versions from Snow Leopard

It may be as simple as making sure the "arch" value is set correctly.

Can you post some of the compiler output, especially the gcc command line?

Thanks again
Dave

[CarinaPDX]

Strange things happening here. Yesterday I opened terminal and just for fun tried "make" again - it ran with i386. A bunch of libraries needed to be reinstalled with "universal" switch. After that, I tried to make again, and I was back to i686! Still that way.

I checked CMakeLists.txt, and it seems that ARCH is set to i386 for "not win32", so I don't have a clue why it isn't working right.

I am not seeing the gcc command line, which would be nice to know. Perhaps there is some switch to make the output verbose?

The response to make is:

Pancho:build_carbon greg$ make
[ 1%] Building CXX object CMakeFiles/GARMINHOST.dir/src/garmin/jeeps/garmin_wrapper.cpp.o
In file included from /opt/local/include/wx-2.8/wx/mac/glcanvas.h:4,
from /opt/local/include/wx-2.8/wx/glcanvas.h:60,
from /Users/greg/opencpn/include/chcanv.h:42,
from /Users/greg/opencpn/include/navutil.h:46,
from /Users/greg/opencpn/src/garmin/jeeps/garmin_wrapper.h:32,
from /Users/greg/opencpn/src/garmin/jeeps/garmin_wrapper.cpp:22:
/opt/local/include/wx-2.8/wx/mac/carbon/glcanvas.h:49: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48)
/opt/local/include/wx-2.8/wx/mac/carbon/glcanvas.h:53: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48)
i686-apple-darwin10-g++-4.2.1: -lgtk-x11-2.0: linker input file unused because linking not done
i686-apple-darwin10-g++-4.2.1: -lgdk-x11-2.0: linker input file unused because linking not done
i686-apple-darwin10-g++-4.2.1: -latk-1.0: linker input file unused because linking not done
i686-apple-darwin10-g++-4.2.1: -lpangocairo-1.0: linker input file unused because linking not done

and continues on for many other libs. Then to Garminhost, etc, with similar errors.

Any ideas for tracking down the i386/686 problem?

BTW libgtk-x11-2.0 and libgdk-x11-2.0 were the only files I couldn't find in MacPorts to rebuild as universal; do you know which package they are in?

[bdbcat]

Greg....

To get more verbose make output, edit CMakeLists.txt and un-comment the following line:

SET(CMAKE_VERBOSE_MAKEFILE ON)

Then $make as usual. Lots of output, including the gcc command lines we need.

Dave

[CarinaPDX]

Dave-

Attached is the first part of the verbose output. The arch is set properly in the compiler invocations (arch=i386). Any more ideas? Greg

[CarinaPDX]

Just found this: Re: [CMake] cmake on Snow Leopard

I tried to add "CMAKE_OSX_ARCHITECTURES=i386;ppc" to the CMakeLists.txt file, but then got this error:

Parse error. Expected a command name, got unquoted argument with text "CMAKE_OSX_ARCHITECTURES=i386;ppc".

Eventually I added "SET (CMAKE_OSX_ARCHITECTURES i386;ppc)" which did cause the compiler to invoke both architectures, but still had the same errors.

I'm lost

[bdbcat]

Greg....

I looked at the Verbose output, and at least in the snippet attached, I could find no error. Lots of warnings about unused libraries during the compile stage.

Good news: We do see one intermediate library linked correctly.
p { margin-bottom: 0.08in; } [7%] Built target GARMINHOST


So linking seems to work.



I guess we need to see it all, especially any later link stages.
It really is not as bad as this output looks, I don't think

Thanks
Dave

[CarinaPDX]

Dave,

OK, I guess I just got spooked by the linker errors. I think the cmake command is now working, but there seems to be an error in the make install. Attached are the logs for the install (the cmake log is too big to upload). And thanks so much for the help. As for what we are trying to accomplish here, I suppose the goal is to get a dmg that will support 10.4-10.6 directly, including ppc, which should also run on Lion (10.7) but without the spiffy Lion stuff. Lion (and later), cocoa, 64 bits and wx v3 seem to be a package deal (headache) for later.

Thanks again,

Greg

[bdbcat]

Greg....

Good progress. Still some trouble finding/installing/fixuping the builtup plugins, but we can skip that for now.

Major problem is the "app verify" stage, where he tries to confirm that all prerequisites are satisfied. It is failing that step.

Try this: after the failed $make install step, you should find a completed (leftover) app bundle at

/Users/greg/tmp/bin/OpenCPN.app

If you try to execute that app, we may get some idea of missing libraries. Or, it might just run. Give it a try.

I'm going to do a verbose build locally on Leopard, and try to compare my output with yours.

Courage!
Dave

[CarinaPDX]

Hi Dave-

It seems to execute just fine. It picked up my old (2.5) pref file and loaded the ENC, BSB, and C-Map charts; they all seem to display just fine.

Back to you,

Greg