Back to failure with raspberry pi and compiling

[jimseng]

Hello all.
The Raspbian image is out that uses the floating point hardware and naturally I had to get opencpn running on it. I succeeded on an earlier debian image using pre-compiled binaries from here: Index of /ticki

I spent ages trying to get them to work on the new hf image but failed. (error openeing shared libraries)
I have tried compiling wxwidgets on my pi. I can but not with "--with-opengl"
with the "non opengl" version of wxwidgets the opencpn binary no longer complains about not finding the libraries but won't run. (Oh no, I would have to spend hours re-compiling wxwidgets to remember what the error was, I really must back up compiled binaries).

So I am trying to compile opencpn from scratch and I get this error:
/home/pi/opencpn/include/chcanv.h:147:13: error: 'GLuint' does not name a type
Is this related?
If I install wxwidgets using apt-get then the version is non unicode and non debug and opencpn complains: "error while loading shared libraries: libwx_baseud-2.8.so.0: cannot open shared object file: No such file or directory" because the libraries installed are without the "ud" suffix.
Sorry to waffle but I have been floundering around in ignorance!

[bdbcat]

jimseng...

I am following Raspberry PI with interest.

Two points:
1. OCPN V 3.0 build process does not do a good job if OpenGL is not found. That causes the GLuint not found message. This needs work, and is on the list.

2. Non-unicode version has similar issues.

It would help if we could see the output of cmake, to try and determine what libraries and include files are going to be used in the build. I'm sure it can be made to work, with some fiddling. Resulting performance of O is the big question....

Dave

[jimseng]

Thanks for the reply

Yes. Surely the performance will be frustrating but from an academic point of view...
Anyway. I recompiled wxwidgets successfully and the downloaded opencpn binary for arm fails with this:
./opencpn: Symbol `_ZTV13TiXmlDocument' has different size in shared object, consider re-linking
./opencpn: symbol lookup error: ./opencpn: undefined symbol: _ZN11TiXmlString8nullrep_E

As I say. I have had this working on the stock Debian wheezy on my Pi.
As for compiling it from scratch this time round...

Attached is the output from cmake (it's actually just a plain text file, not a .doc)

And here is the opencpn compilation failure: (sorry about the â character...putty on windows does that sometimes doesn't it.)

[ 8%] Building CXX object CMakeFiles/GARMINHOST.dir/src/garmin/jeeps/garmin_wrapper.cpp.o
In file included from /home/pi/opencpn/include/navutil.h:45:0,
from /home/pi/opencpn/src/garmin/jeeps/garmin_wrapper.h:32,
from /home/pi/opencpn/src/garmin/jeeps/garmin_wrapper.cpp:22:
/home/pi/opencpn/include/chcanv.h:147:13: error: âGLuintâ does not name a type
/home/pi/opencpn/include/chcanv.h: In constructor âemboss_data::emboss_data()â:
/home/pi/opencpn/include/chcanv.h:140:41: error: âgltexindâ was not declared in this scope
/home/pi/opencpn/include/chcanv.h: At global scope:
/home/pi/opencpn/include/chcanv.h:564:1: error: invalid use of incomplete type âstruct wxGLCanvasâ
/home/pi/opencpn/include/ocpndc.h:50:7: error: forward declaration of âstruct wxGLCanvasâ
/home/pi/opencpn/include/chcanv.h:622:7: error: âGLuintâ does not name a type
/home/pi/opencpn/include/chcanv.h:623:7: error: âGLuintâ does not name a type
/home/pi/opencpn/include/chcanv.h:625:7: error: âGLenumâ does not name a type
/home/pi/opencpn/include/chcanv.h:626:7: error: âGLuintâ does not name a type
/home/pi/opencpn/include/chcanv.h:627:7: error: âGLuintâ does not name a type
In file included from /home/pi/opencpn/include/chartdbs.h:39:0,
from /home/pi/opencpn/include/navutil.h:48,
from /home/pi/opencpn/src/garmin/jeeps/garmin_wrapper.h:32,
from /home/pi/opencpn/src/garmin/jeeps/garmin_wrapper.cpp:22:
/home/pi/opencpn/include/chartbase.h:177:47: error: âwxGLContextâ does not name a type
/home/pi/opencpn/include/chartbase.h:177:60: error: ISO C++ forbids declaration of âglcâ with no type [-fpermissive]
In file included from /home/pi/opencpn/include/chartdbs.h:39:0,
from /home/pi/opencpn/include/navutil.h:48,
from /home/pi/opencpn/src/garmin/jeeps/garmin_wrapper.h:32,
from /home/pi/opencpn/src/garmin/jeeps/garmin_wrapper.cpp:22:
/home/pi/opencpn/include/chartbase.h:272:47: error: âwxGLContextâ does not name a type
/home/pi/opencpn/include/chartbase.h:272:60: error: ISO C++ forbids declaration of âglcâ with no type [-fpermissive]
/home/pi/opencpn/include/chartbase.h:321:53: error: âwxGLContextâ does not name a type
/home/pi/opencpn/include/chartbase.h:321:66: error: ISO C++ forbids declaration of âglcâ with no type [-fpermissive]
make[2]: *** [CMakeFiles/GARMINHOST.dir/src/garmin/jeeps/garmin_wrapper.cpp.o] Error 1
make[1]: *** [CMakeFiles/GARMINHOST.dir/all] Error 2
make: *** [all] Error 2

[bdbcat]

jimseng...

Odd.
cmake shows that openGL is found. But GLint is not...

So, we need more verbose makefile output.

Please edit CMakeLists.txt, and uncomment (remove '#')

#SET(CMAKE_VERBOSE_MAKEFILE ON)

re-run cmake, and make again. the make log will show complete gcc command lines emitted by make.

e.g.

[ 45%] Building CXX object CMakeFiles/opencpn.dir/src/chart1.cpp.o
/usr/bin/c++   -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ -DUSE_GLU_TESS -DBUILD_WITH_LIBGPS -DTIXML_USE_STL -DUSE_S57 -DUSE_GARMINHOST -pthread -isystem /usr/lib/wx/include/gtk2-unicode-debug-2.8 -isystem /usr/include/wx-2.8 -I/home/dsr/Desktop_Old/opencpn/include -I/home/dsr/Desktop_Old/opencpn/src -I/home/dsr/Desktop_Old/opencpn/src/nmea0183 -I/usr/local/include -I/home/dsr/Desktop_Old/opencpn/src/mygdal -I/home/dsr/Desktop_Old/opencpn/src/garmin/jeeps   -Wall -Wno-unused -fexceptions -rdynamic  -g -fno-strict-aliasing -o CMakeFiles/opencpn.dir/src/chart1.cpp.o -c /home/dsr/Desktop_Old/opencpn/src/chart1.cpp

This will tell us where the include files are coming from

Dave

[monstads]

I just got my PI last night, and one of the first things I did was compile Opencpn.

Using the raspian image with hard float.
Followed the "buiding with Linux" page on opencpn.org to a tee, on a virgin raspian image. Basically, just copy/pasted the 'sudo apt-get install ....." line.
Pulled latest code from Git
Followed the ../cmake , make sequence
I did notice that opengl was found (looked like the proprietary one, can get the exact path if needed)
Opencpn compiled without a hitch


Still having some trouble with my hardware, so I ran it over an X session to my Ubuntu box with X forwarding over SSH.

What I've seen so far
1) It compiles !
2) It runs ! (walks)
3) The sample Puerto Rico KAP chart from "chart sources" loads fine
4) The "hard float" image is *way* faster than I expected for general OS work. Need to confirm that O is actually compiling using hard float
5) RAM is a problem, and it looks like it's doing a fair amount of swapping
6) Inland water way ENC charts (broken link on "chart sources" page, btw; remove last part of the URI to fix) I have not gotten to render yet. Might be something I'm doing wrong, but haven't had a chance to dig into it yet
7) Even with the raster chart, basic operations like zoom and pan are "click and wait". Still, it's better than I feared it would be.

[jimseng]

Monstads...That's really unfair that you got it to work and I didn't! I am going to try a completely fresh install like you did and see what happens. I will get some more verbose output and as well just in case. I was using CM93 charts on the non HW float version and yes it was click and wait but I was trying it on a 1920 x x1080 TV. I wonder what this Raspbian image at a resolution for a screen more suitable for a boat would be like. Thanks for the help guys, I'll see how far I get over the weekend but there seems to be a moment of summer coming so hunching over a keyboard takes second place to sailing. (+ I want to escape the Olympics). I might see if I can hook the Pi up to the data box and see if I can read the nmea stuff from the instruments. Dunno what to do with it though. Put it on Twitter?

[miatapaul]

I will keep an eye on this as I think the Raspberry has a great potential for this, plus I have a touch screen just looking for a project. (it even has 12 volt input) So I almost have a chart plotter, now just need to get a boat to put it on! :-)

[monstads]

Jimseng, trust me, it was not from anything brilliant on my end. I hope you get yours working.

For anyone else with a PI , I would recommend downloading the O source code and compiling it yourself. it really is as easy as the excellent instructions on the website.

Using the GPIO pins (with an IOExtender type board) to read NMEA and other sensors is exactly what I'm thinking as well. Probably do an Android app to display the data.

[jimseng]

Uh?
I did a completely fresh SD card with the Raspbian image, followed the linux compile instructions and my make failed with this:

*** glibc detected *** /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1plus: free(): invalid next size (fast): 0x013559f8 ***
In file included from /home/pi/opencpn/src/garmin/jeeps/garmin_wrapper.h:32:0,
from /home/pi/opencpn/src/garmin/jeeps/garmin_wrapper.cpp:22:
/home/pi/opencpn/include/navutil.h:179:7: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
make[2]: *** [CMakeFiles/GARMINHOST.dir/src/garmin/jeeps/garmin_wrapper.cpp.o] Error 1
make[1]: *** [CMakeFiles/GARMINHOST.dir/all] Error 2
make: *** [all] Error 2


I am overclocked, just in case that is relevent.

[jimseng]

Ha. I think it was the overclocking, certainly this time round. I have it compiled but I can't test it because I am off sailing for a few days.
Monstads. I have bought one of these: USB To RS232 TTL PL2303HX Auto Converter Module Converter Adapter 5V 3.3V Output | eBay
A few quid and I think it will USB straight into the Pi to read nmea from the boat data box. I was thinking exactly the same...having the boat instruments stream to my Android phone (I don't know why!). It was very trivial to output serial to to a Microchip Pic so I guess one day I would like to have the Pi with a touch screen as the central computer and some pics here and there doing LED dimming/cabin lights and who knows what else.

[monstads]

Glad you got it compiled, and good on you for prioritizing sailing! The USB to rs232 connector looks interesting. For sure let me know if it works, as I was under the impression there was a bit more to it, and the NMEA to USB bridges I've seen are quite a but pricier.

I am definitely also in the "have solution, need a good problem " mode. Right now I want to see how far I can take opencpn on it, and do some sensor input. Once the dark and cold sets in, I'm sure I'll get more ambitious....

[Cingulingu]

Originally Posted by monstads

I just got my PI last night, and one of the first things I did was compile Opencpn.

Using the raspian image with hard float.
Followed the "buiding with Linux" page on opencpn.org to a tee, on a virgin raspian image. Basically, just copy/pasted the 'sudo apt-get install ....." line.
Pulled latest code from Git
Followed the ../cmake , make sequence
I did notice that opengl was found (looked like the proprietary one, can get the exact path if needed)
Opencpn compiled without a hitch


Still having some trouble with my hardware, so I ran it over an X session to my Ubuntu box with X forwarding over SSH.

What I've seen so far
1) It compiles !
2) It runs ! (walks)
3) The sample Puerto Rico KAP chart from "chart sources" loads fine
4) The "hard float" image is *way* faster than I expected for general OS work. Need to confirm that O is actually compiling using hard float
5) RAM is a problem, and it looks like it's doing a fair amount of swapping
6) Inland water way ENC charts (broken link on "chart sources" page, btw; remove last part of the URI to fix) I have not gotten to render yet. Might be something I'm doing wrong, but haven't had a chance to dig into it yet
7) Even with the raster chart, basic operations like zoom and pan are "click and wait". Still, it's better than I feared it would be.

Good JOB. The problem in compiling it is very easy. For all of you who want to do it there is a simple solution. Witch actually will do a better PI all together.
I suggest you to use a fast SD as possible and at last 8-16 GB. My suggestion is the card in the first point. Work beautifully. 6-7 to boot + 9 seconds for X

Using: WHEEZY

1. Make an installation from that thread: Raspberry Pi &bull; View topic - Pi with 16GB SanDisk Extreme Class 10 45MB/s WORKING
This will solve many problems around the SD card,kernel,peripherals,...
2. Configure it to your needs eg. RPi config.txt - eLinux.org , key-map, Locale,...
3. When all the work is done, you will have a fast RPI, now do:
sudo apt-get update ,a cuple of time until it finish without error. "Yes, again!"
4. Do the step above as "monstads" describe.
5. Take a break, It takes a long time

Done

[Alisdair]

I've given up on raspbian armhf wheezy for OpenCPN due to failures to work with vector charts (see separate post).

I have, however, had quite a bit of success using the old Debian SD squeeze image, latest OpenCPN (3.1.802), 224MB memory split, and overclocking to 900MHz. I haven't even felt the need to change the config file or turn off quilting.

[jimseng]

Alisdair
Interesting. I was going to ask why my CM93 chart don't work. Pity because it is too slow IMO ad I was hoping hard float would sort this out. What thread are you referring to?

[Alisdair]

Originally Posted by jimseng

Alisdair
Interesting. I was going to ask why my CM93 chart don't work. Pity because it is too slow IMO ad I was hoping hard float would sort this out. What thread are you referring to?

http://www.cruisersforum.com/forums/...-pi-86528.html