Trying to Build Mac Version

[bdbcat]

Greg....

It runs! I guess there are no PlugIns?

There seems to be problem fixing-up some of the libraries which are included in the app bundle. I suppose if you run the app directly, the libraries get pulled in from /opt/local...., and not from the bundle. Just guessing...

This is an interesting error:
p { margin-bottom: 0.08in; }

72/88: fixing up '/Users/greg/tmp/bin/OpenCPN.app/Contents/MacOS/libpango-1.0.0.dylib'
 install_name_tool: changing install names or rpaths can't be redone for: /Users/greg/tmp/bin/OpenCPN.app/Contents/MacOS/libpango-1.0.0.dylib (for architecture i386) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)

Anyway, I'll keep reading about all this, and see if I can find a modern Mac to work with for a few hours.

You should be able to do some limited testing on the 2.6 app in your environment in the meantime.

Thanks
Dave

p.s. I'm at the loose end of a satellite internet connection bridged to a 1 mile Wifi link. Solar flares are killing me....

On the other hand, I'm at Staniel Cay in the Bahamas, and the water is beautiful.

So we make our choices....

[CarinaPDX]

Dave-

I confirm that there are no plug-ins.

As noted before, this is all a bit over my head. I get the basic outline of what you are doing, but I am missing a proper detailed understanding of the process. So debugging isn't going to be a big contribution from this end. That said, I will take a look at libpango and see if anything shows up.

Part of the problem has been that my MacPorts is a mess of 64 bit and 32/64 bit libs. I also wonder if the make install tries to bring in dylibs from my system, and whether they include 32 bit code. I suspect this would be easier starting from a clean install of the OS and MacPorts, then setting universal as the MacPorts default before doing anything else. Live and learn...

Too bad about the internet connection. I am dog/house sitting for an old friend that is on sabbatical from Intel, and the connection here is just stunning. OTOH it is cold and rainy with no end in sight. I'd trade in a heartbeat...

Greg

[bdbcat]

Greg....

I just read some stuff (Google "install_name_tool: changing install names or rpaths can't be redone") that seems to say that we need to use macports to get pango, and change the config before it is compiled.

Something like:

$sudo port configure pango

with
configure.ldflags-append -headerpad_max_install_names

somewhere/somehow applied.

I don't know Macports well, and this will never happen on my Wifi connection anyway....

Good luck
Dave

[CarinaPDX]

Dave-

Both my GTK2 and pango MacPorts packages were done with the "x11" flag (and I don't know why). Could installing the no-x11 variants help?

As for modifying the config, I will look into that but I'm not optimistic. The whole point of MacPorts is to automate the install. This would require stopping the process in the middle, modify, then restart. I'll look but I'm not holding my breath. Greg

[Patient]

I am going to attempt a build tonight on a MacBook7,1 with Snow Leopard. I am a part time cocoa developer and will perhaps post an exhaustive guide along the way.

Updates to come.

[Patient]

Complied OpenCPN successfully tonight. I have yet to work through some library issues though so can't get very far.

I am documenting my problem solving along the way though and plan on providing that when I get a stable app running.

Using Xcode 4.0 and cmake version 2.8.7

Here's my MacBook specs if anyone is interested.

Darwin kiva 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386 MacBook5,1 Darwin

[CarinaPDX]

Dave-

I finally got back to this with the new build (1609). Basically my MacPorts had got into a tangled mess by my trying to change old 64 bit ports to 32+64 bits (universal). So I removed the entire MacPorts install and started over, using the "+universal" variant on everything I installed. The only other (non-default) variant I used was the "+libusb" variant for gpsd, which I take is best for connecting to a USB GPS puck.

The following was installed with MacPorts:

Cmake
git-core
gpsd
gtk2
tinyxml
wxwidgets (2.8.x, not dev 2.9.x)

I made it through "make" with very few errors. At the beginning it didn't find the gps library, otherwise it went a long ways. Could you please look at this and see if there is anything to do to get it to work? I had to cut out the loooong middle section of the log, so I hope this is enough.

I am concerned that changes made to develop for 64-bit Cocoa may inadvertently have caused problems for the 32-bit Carbon build. (There are error messages relating to the architecture.)

Greg

[bdbcat]

Greg....

Our CMakeLists.txt is too simplistic. It sees your 64 bit system, and concludes that you want a native 64 bit build. Says so in the attached build log at line 30.

We'll have to do better.

Meanwhile, you may move forward by editing the CMakeLists.txt file, and fixing it at line 87

  IF(APPLE)
#    IF (CMAKE_SIZEOF_VOID_P MATCHES "8")
#     SET(ARCH "x86_64")
# ENDIF (CMAKE_SIZEOF_VOID_P MATCHES "8")
  ENDIF()

note the # comment markers.

This should cause the default i386 architecture to be used.

Gotta think about a cmake command line switch to make this work for either 32 or 64 bit systems.

Good luck
Dave

[CarinaPDX]

Dave,

That did the trick - "make" worked well. The only problem I am picking up from the log is that it can't find the gps library - how do I fix that? Is it necessary for my USB GPS to work? (I'd try it myself but I can't find it at the moment.)

The program executes (after make, no install or dmg) and the warning dialog comes up. After dismissing, the current chart (from the current installed ocpn 2.5 state) is displayed, and looks good. The toolbar works, and can be moved (nice). The zoom buttons work, but I can't select the chart from the bottom bar. Thus I can't switch out of NOAA S57 to raster or cm93. The arrow keys work to pan the chart, but I can't drag the chart to pan.

Obviously this needs more testing, but it is looking pretty good. I suppose the next step is either to make a dmg or try to build for 10.5 as well as 10.6. And then 10.4u to try and pick up powerpc macs.

Any guidance greatly appreciated.

Greg

[CarinaPDX]

I found my GPS puck and plugged it in - it works just fine with this build. So whatever the gps library not found message is about, it doesn't prevent the gps working. The boat icon shows correctly, and the lat/lon/sog/cog are displayed on the bottom.

However, I have found that, in addition to the previous non-responsiveness noted, I cannot access further info on the objects on the chart. Also, the cursor location on the bottom line does not change. Basically, there seems to be no interaction between the cursor and chart window. But there is an interaction with the toolbar. It all sounds like one modest bug, but I have no idea how to find it. If you have any ideas how I may help, let me know.

Greg

[felixfi]

Hello,

I am new here, but I was looking around for a discussion on how to compile the latest OpenCPN on a Mac.

Following your discussion and applying some of your advices I was also able to compile and run the latest version.

Screen shot 2012-04-21 at 18.52.17.jpg Views: 123 Size: 411.8 KB ID: 40224" style="margin: 2px" />

I had to force the 32 bits version (using bdbcat fix to comment some lines in the CMakeLists.txt)

I also get a recurrent warning about a deprecated type (this warning seems to come from wx-2.8 code).

/usr/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)
/usr/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)

Last, I also get a pop up when starting OpenCPN complaining about an assert (see my screen dump).

A part from that, the application launches and display a map.

My 2 cents for now.

Felix

[CarinaPDX]

I just pulled down the 2.6.1705 source and tried to build a Mac 32 bit version. The make went OK without modifying anything, but there were a few errors with the make install: libdashboard_pi.dylyb and libgrib_pi.dylib were half the problem. I can confirm that they exist in /Users/greg/opencpn/plugins/dashboard_pi and grib_pi. There were also two errors relating to install_name_tool. Any ideas?

Attached is the build log.

[CarinaPDX]

BTW the executable in the tmp folder seems to run well, with the exception of the depth numbers which are black rectangles.

[CarCode]

CarinaPDX,
try the ready to go dmg file from Download OpenCPN | Official OpenCPN Homepage
and see what is wrong with 1705.
It is not your fault.

Gerhard

[CarinaPDX]

Gerhard- Thanks for the response.

I only mentioned the 1705 text bug in passing - I am not attempting to test the app at this point.

I am trying to first create a dmg installer for 10.6, duplicating what has been done. Basically this is to ensure that the process works - and at this point it doesn't, although the problems seem to be few and should be easy to fix.

Then I want to try to build for 10.5, and then 10.4u (including ppc). If that is successful then we could offer a version for older systems.

I am hoping to get this working with the next stable release - 1705 for me is just for checking the process.