Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 25-05-2012, 17:38   #46
Registered User

Join Date: Jul 2011
Posts: 12
Re: OpenCPN Version 2.6 Beta Build 1723

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....)
__________________

__________________
Ocean_master is offline   Reply With Quote
Old 25-05-2012, 17:51   #47
Registered User

Join Date: Dec 2008
Boat: Journeyman
Posts: 705
Re: OpenCPN Version 2.6 Beta Build 1723

Quote:
Originally Posted by Ocean_master View Post
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?
__________________

__________________
JesperWe is offline   Reply With Quote
Old 25-05-2012, 17:53   #48
Registered User

Join Date: Jul 2011
Posts: 12
Re: OpenCPN Version 2.6 Beta Build 1723

Quote:
Originally Posted by JesperWe View Post
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
__________________
Ocean_master is offline   Reply With Quote
Old 25-05-2012, 17:57   #49
Registered User

Join Date: Dec 2008
Boat: Journeyman
Posts: 705
Re: OpenCPN Version 2.6 Beta Build 1723

Quote:
Originally Posted by Ocean_master View Post
Sensible value now and all ok
Good. And the rendering of those texts will be improved sometime post 3.0 release.
__________________
JesperWe is offline   Reply With Quote
Old 25-05-2012, 21:16   #50
Registered User
 
sbfreddie's Avatar

Join Date: Mar 2012
Location: Southern Texas, Port Isabel
Boat: I Wish
Posts: 164
Images: 1
Send a message via Skype™ to sbfreddie
Re: OpenCPN Version 2.6 Beta Build 1723

Quote:
Originally Posted by bdbcat View Post
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
__________________
sbfreddie is offline   Reply With Quote
Old 26-05-2012, 07:58   #51
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,877
Re: OpenCPN Version 2.6 Beta Build 1723

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
__________________
bdbcat is offline   Reply With Quote
Old 26-05-2012, 11:04   #52
Registered User

Join Date: Dec 2005
Location: WNA
Boat: Dufour 35
Posts: 3,247
Re: OpenCPN Version 2.6 Beta Build 1723

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
__________________
cagney is offline   Reply With Quote
Old 26-05-2012, 13:43   #53
Registered User
 
sbfreddie's Avatar

Join Date: Mar 2012
Location: Southern Texas, Port Isabel
Boat: I Wish
Posts: 164
Images: 1
Send a message via Skype™ to sbfreddie
Re: OpenCPN Version 2.6 Beta Build 1723

Quote:
Originally Posted by bdbcat View Post
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:

Click image for larger version

Name:	Activity Moniter Window for OpenCPN.png
Views:	60
Size:	71.9 KB
ID:	41528

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:

Click image for larger version

Name:	Activity <a title=Monitor for O 1723.png Views: 49 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
__________________
sbfreddie is offline   Reply With Quote
Old 26-05-2012, 15:36   #54
Registered User

Join Date: Dec 2008
Boat: Journeyman
Posts: 705
Re: OpenCPN Version 2.6 Beta Build 1723

Quote:
Originally Posted by cagney View Post
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....)
__________________
JesperWe is offline   Reply With Quote
Old 26-05-2012, 17:26   #55
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,877
Re: OpenCPN Version 2.6 Beta Build 1723

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
__________________
bdbcat is offline   Reply With Quote
Old 26-05-2012, 18:46   #56
Registered User
 
sbfreddie's Avatar

Join Date: Mar 2012
Location: Southern Texas, Port Isabel
Boat: I Wish
Posts: 164
Images: 1
Send a message via Skype™ to sbfreddie
Re: OpenCPN Version 2.6 Beta Build 1723

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
__________________
sbfreddie is offline   Reply With Quote
Old 26-05-2012, 22:16   #57
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,877
Re: OpenCPN Version 2.6 Beta Build 1723

Freddie....

Or maybe the other way around.

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

Code:
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
__________________
bdbcat is offline   Reply With Quote
Old 27-05-2012, 11:12   #58
Registered User

Join Date: Feb 2011
Posts: 488
Re: OpenCPN Version 2.6 Beta Build 1723

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
__________________
P_Dub is offline   Reply With Quote
Old 27-05-2012, 11:44   #59
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,877
Re: OpenCPN Version 2.6 Beta Build 1723

P_dub...

Picture, please?

Thanks
Dave
__________________
bdbcat is offline   Reply With Quote
Old 27-05-2012, 12:07   #60
Registered User

Join Date: Dec 2005
Location: WNA
Boat: Dufour 35
Posts: 3,247
Re: OpenCPN Version 2.6 Beta Build 1723

Dave

This is a similar issue:

Torres Strait, Ebb Stream And Flood Stream running in opposite directions, but uses the same, unrelated, icon.
Click image for larger version

Name:	torres strait2.png
Views:	62
Size:	65.9 KB
ID:	41543

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

Name:	torres strait1.png
Views:	56
Size:	187.8 KB
ID:	41544

Thomas
__________________

__________________
cagney is offline   Reply With Quote
Reply

Tags
opencpn

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off




Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 10:40.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.