OpenCPN Version 2.6 Beta Build 1723

[Ocean_master]

well well chart text was set to 72.....beta 1723 must have changed that as 1628 was correct size.

Windoes home and GL on and off (I test both just incase now....)

[JesperWe]

Originally Posted by Ocean_master

well well chart text was set to 72....

Well that IS kind of large... So if you set it to a sensible value everything is OK now?

[Ocean_master]

Originally Posted by JesperWe

Well that IS kind of large... So if you set it to a sensible value everything is OK now?

Sensible value now and all ok

[JesperWe]

Originally Posted by Ocean_master

Sensible value now and all ok

Good. And the rendering of those texts will be improved sometime post 3.0 release.

[sbfreddie]

Originally Posted by bdbcat

freddie....

The build errors you show relate to PlugIns, and should not prevent normal operation of OpenCPN. PlugIns won't be found, and O will carry on happily.

Try this:
$cd ~/Library/Preferences
$rm opencpn.ini

This will force O to start with a new default config file, in standard (DC) mode. Load some charts, play around, and take note of any crashes. Try OpenGL mode, with fingers crossed.

I imagine that vector charts will be more likely to crash on the Mac....

Good Luck
Dave

Dave:
I rebuilt again, and dumped the opencpn.ini file, but O still crashes right away with the same EXC_CRASH (SIGTRAP). There still are no dylibs in the app bundle at /Contents/MacOS folder this is more than likely the reason for the crash. The Plugins folder is there with the plugin dylibs.
This is the guilty culprit thats missing:

Exception Type: EXC_CRASH (SIGTRAP)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x959b7c5a __kill + 10
1 libSystem.B.dylib 0x959b7c4c kill$UNIX2003 + 32
2 libSystem.B.dylib 0x95a4a5a5 raise + 26
3 libwx_macud-2.8.0.dylib 0x004ff000 wxTrap() + 18
4 libwx_macud-2.8.0.dylib 0x0062654e wxGUIAppTraitsBase::ShowAssertDialog(wxString const&) + 218
5 libwx_macud-2.8.0.dylib 0x004d349c 0x4cc000 + 29852
6 libwx_macud-2.8.0.dylib 0x004d35a6 wxOnAssert(wchar_t const*, int, char const*, wchar_t const*, wchar_t const*) + 173
7 libwx_macud-2.8.0.dylib 0x004d875d wxMacCFStringHolder::Assign(wxString const&, wxFontEncoding) + 229
8 libwx_macud-2.8.0.dylib 0x005be4eb wxFontRefData::MacFindFont() + 817
9 libwx_macud-2.8.0.dylib 0x005be8c6 wxFont::RealizeResource() + 20
10 libwx_macud-2.8.0.dylib 0x005beb5e wxFont::Create(int, int, int, int, bool, wxString const&, wxFontEncoding) + 130
11 libwx_macud-2.8.0.dylib 0x005bebb3 wxFont::Create(wxNativeFontInfo const&) + 69
12 libwx_macud-2.8.0.dylib 0x0064d0e2 wxFont::wxFont(wxNativeFontInfo const&) + 68
13 libwx_macud-2.8.0.dylib 0x0064b431 wxFontBase::New(wxNativeFontInfo const&) + 41
14 libwx_macud-2.8.0.dylib 0x0064c794 wxFontBase::New(wxString const&) + 136
15 0x000d6327 FontMgr::GetFont(wxString const&, int) + 247 (navutil.cpp:6722)
16 0x000c93fa AnnunText::RefreshFonts() + 58 (concanv.cpp:514)
17 0x000c98cf AnnunText::AnnunText(wxWindow*, int, wxString const&, wxString const&) + 607 (concanv.cpp:473)
18 0x000ca0a2 ConsoleCanvas::ConsoleCanvas(wxWindow*) + 1634 (concanv.cpp:99)
19 0x0005039e MyApp::OnInit() + 8702 (chart1.cpp:2595)
20 0x00054481 wxAppConsole::CallOnInit() + 17 (app.h:76)
21 libwx_macud-2.8.0.dylib 0x00534c84 wxEntry(int&, wchar_t**) + 96
22 0x000219e8 main + 24 (chart1.cpp:1652)
23 0x0001f789 start + 53

libwx_macud-2.8.0.dylib is missing as well as all the other dylibs that belong in the /Contents/MacOS folder with the app file OpenCPN.

TIA,
Freddie

[bdbcat]

Freddie...

I need to get oriented here, so pardon me if these questions are redundant.

1. Does the last 2.6.1718.dmg (available at opencpn.org) start and run on your system?

2. Where did the libwx_macud-2.8.0.dylib on your system come from? Did you build it, or download it from somewhere?

Here is what I think:
The libwx that is part of the .dmg that I made was built from source on my 10.5 system. So it works on my system, as expected.

The libwx_macud that you have seems not compatible with OpenCPN, somehow. From the crash log, it is clearly being called, and crashing inside the library, at essentially the first real library call.

One thing to think about is the the "ud" suffix in "libwx_macud" usually means that library is "Unicode-Debug" flavor. The "Debug" part may be the problem, since you are building OpenCPN as "Unicode-Release" flavor.

The cmake build script selects the "best" (or only) set of wxWidgets libraries to link. In your case, it is finding "ud".

Have a look around your system, looking for libwx_macu-2.8.0.dylib, the Unicode-Release flavor. If you find it, maybe temporarily rename the "ud" libraries, so that the cmake script will be forced to select the "u" variety. Run cmake again. See what happens.

I could, of course, put my premade Mac wxlibraries into the source repo, just like we do on Windows. I'd rather avoid this, since Mac is essentially unix, and should do a better job of dylib management than Windows.

Lets keep working this as best we can.
I'm still looking around for the right modern 10.6 64-bit Mac to add to my stable of build machines. Think about a Mac Mini....

Dave

[cagney]

Many users have requested that text labels on vector-charts always stays horizontal in course up mode. What happened to this request?
Well this feature has sneaked into 2.6 in OpenGL mode, without anyone really noticing, as far as I can tell. Anyhow it does work now!


Thomas

[sbfreddie]

Originally Posted by bdbcat

Freddie...

I need to get oriented here, so pardon me if these questions are redundant.

1. Does the last 2.6.1718.dmg (available at opencpn.org) start and run on your system?

2. Where did the libwx_macud-2.8.0.dylib on your system come from? Did you build it, or download it from somewhere?

Here is what I think:
The libwx that is part of the .dmg that I made was built from source on my 10.5 system. So it works on my system, as expected.

The libwx_macud that you have seems not compatible with OpenCPN, somehow. From the crash log, it is clearly being called, and crashing inside the library, at essentially the first real library call.

One thing to think about is the the "ud" suffix in "libwx_macud" usually means that library is "Unicode-Debug" flavor. The "Debug" part may be the problem, since you are building OpenCPN as "Unicode-Release" flavor.

The cmake build script selects the "best" (or only) set of wxWidgets libraries to link. In your case, it is finding "ud".

Have a look around your system, looking for libwx_macu-2.8.0.dylib, the Unicode-Release flavor. If you find it, maybe temporarily rename the "ud" libraries, so that the cmake script will be forced to select the "u" variety. Run cmake again. See what happens.

I could, of course, put my premade Mac wxlibraries into the source repo, just like we do on Windows. I'd rather avoid this, since Mac is essentially unix, and should do a better job of dylib management than Windows.

Lets keep working this as best we can.
I'm still looking around for the right modern 10.6 64-bit Mac to add to my stable of build machines. Think about a Mac Mini....

Dave

Dave:
Answer to question 1 is:
Yes, it works just fine because the dylib are included in the build. Here is a snapshot from Activity Monitor of the O app when running:



Notice where the dylibs are located. They are from your build because they are included in the app bundle at /Contents/MacOS. When I build using your instructions the dylibs don't make it into the app bundle so the OS tries to find a suitable replacement which is where the libwx_macud comes into play.

Answer to question 2 is:
On my System libwx_macud-2.8.0.dylib is a universal binary built for PPC & i386 and its located at /usr/lib. This is the dylib its loading, here is a snapshot of the O v1723 I build before it crashes:

Monitor for O 1723.png Views: 105 Size: 52.5 KB ID: 41530" style="margin: 2px" />

The Mac Mini is a very good choice for a boat, it uses very low power, has everything you need built in, and is very powerful considering its size. I have 2, one for my wife and one for my truck. I bought a small switching power supply that converts 12Vdc to the 19Vdc it uses. Its also very durable as I have had it installed in my truck for 5 years and have no problems with it.

Thanks,
Freddie

[JesperWe]

Originally Posted by cagney

Many users have requested that text labels on vector-charts always stays horizontal in course up mode. What happened to this request?
Well this feature has sneaked into 2.6 in OpenGL mode, without anyone really noticing, as far as I can tell. Anyhow it does work now.
Thomas

Oops, that might well be a side effect of all my messing around with the vector code... If it is a good one then all is well. But is it consistent? Both DC and OpenGL? AtoN labels, Light descriptions etc???

(I am in the middle of heavy coding on other stuff, don't really have a good build to test on right now....)

[bdbcat]

jesperwe...

Sort of a side effect, I guess. When we shifted ENC text to overlayed ocpndc rendering, and away from texture mapped fonts, we got text overlays that honor the GL rotation matrix automagically.

All text is affected in GL mode, and I think it is a good thing. This is one of the promises of Vector Charts, that they can be made to do the right thing with text when the chart is rotated. That can never happen on RNC features and texts.

Chart Feature Texts on DC mode are not rotated. In that mode, we simply render the chart fully, and rotate the full bitmap to the desired angle. All rendered features are rotated just like an RNC.

So, one more reason to use OpenGL, if you are able.

Dave

[sbfreddie]

Dave:
I think I have found the core of the problem. On your 10.5 system all builds are i386 (32bit) by default. On all systems 10.6 and above all builds default to x86_64 (64bits). The OpenCPN I am building is x86_64 by default, but the wxWidgets 2.8.0.dylib is only built for i386 (32bit). This is the reason it keeps crashing when trying to use the libwx_macud-2.8.0.dylib. It is also probably the reason the packager is not putting the dylibs into the app bundle as yours does, because they are the wrong architecture.
I have not figured out yet how to tell cmake to build for i386 architecture, but perhaps with your help we can do this.

Thanks,
Freddie

[bdbcat]

Freddie....

Or maybe the other way around.

OpenCPN cmake files are set to default to i386 for Mac, but can be overridden for 64.

219.  64 bit Mac builders note: If you want to build for a 64 bit target on a 64 bit machine, do $cmake -DCMAKE_OSX_64=true ..

From your OpenCPN build log, I see a line:

*** Build Architecture is i386

so, the OpenCPN build is i386 for sure.

However, I seem to remember some discussion about this before. What if the wxWidgets libraries you have by default are 64 bit? That would crash, I suspect...

So, we can do two things:

1. Try to build OpenCPN as 64 bit, as described above, or
2. Get and compile wxWidgets from source in 32 bits.

It is not sufficient to just give you the 32 bit dylibs. The OpenCPN build needs the correct 32 bit include files as well.

I got wxWidgets from MacPorts. I don't know if MacPorts for Snow Leopard can be configured to make 32 bit wxWidgets, or if it insists on 64. I don't have a 10.6 to test on, I'm afraid....

Google time...

Dave

[P_Dub]

On my S57 Charts have the current arrows of CHS pointing Northward and not in the direction that should be. Any idea what to do?
Regards

[bdbcat]

P_dub...

Picture, please?

Thanks
Dave

[cagney]

Dave

This is a similar issue:

Torres Strait, Ebb Stream And Flood Stream running in opposite directions, but uses the same, unrelated, icon.


Route with non mandatory to way traffic. Double arrows with some ?:s and !:s. Can we do better than this?


Thomas