Compiling for ARM on other distros / graphical environment

[johnea]

Hello,

I'm trying to build opencpn for rpi3 on archlinuxarm.

The CMakeLists.txt file will only identify the ARCH as armhf when one of the specific distributions is identified. (deb, rpm, suse, etc)

I tried faking a deb environment by creating: /etc/debian_version

However, the build still fails with:

CMake Error at src/glu/CMakeLists.txt:57 (add_library):
  add_library cannot create target "GLU_static" because another target with
  the same name already exists.  The existing target is a static library
  created in source directory

I'd like to be able to build and run within my working archlinuxarm environment.

Along these lines (sort of a second question) what is the rpi device tree driver configuration expected by opencpn?

In other words, what combination of X11 drivers, and kernel drivers (vc4-kms-v3d, vc4-fkms-v3d) are expected.

Thank you to everyone developing and supporting OpenCPN!

johnea

[seandepagnier]

what distribution are you using?

[johnea]

Originally Posted by boat_alexandra

what distribution are you using?

I'm running ArchLinux for ARM:
https://archlinuxarm.org/

cmake 3.7.2
wxgtk 3.0.2

Thank you boat_alexandra!

johnea

[seandepagnier]

What if you set the ARCH directly can it build?

Can you pull the arch logic out of the distro check logic in CMakeLists? It shouldn't be specific to a distribution anyway.

[conachair]

If it's just a system that works for sailing running on a Pi have you had a look at Openplotter?
Sailing with free hardware | Sailoog
Most things you might need plus lots more.

[johnea]

Hello,

Sorry I didn't reply yesterday. I was out sailing!

10-15 knots and clear skies off San Diego's coast.

Originally Posted by conachair

If it's just a system that works for sailing running on a Pi have you had a look at Openplotter?
Sailing with free hardware | Sailoog
Most things you might need plus lots more.

Hello conachair,

I have an existing archlinux system that I'm using for various applications. I'd really like to be able to build opencpn for that environment, so that I can integrate it with everything else I'm already using.

Openplotter does offer a little info on build:
https://github.com/sailoog/openplotter/wiki

But really all of this is debian/ubuntu specific.

M/V Cesc also offers a little config and build info here:
https://mvcesc.wordpress.com/2017/04...aspberry-pi-3/

This is helpful, but also specific to the debian environment.

I have many years experience in archlinux, and very little in debian. I'd really prefer to run opencpn on my linux distribution of choice.

Originally Posted by boat_alexandra

What if you set the ARCH directly can it build?

Can you pull the arch logic out of the distro check logic in CMakeLists? It shouldn't be specific to a distribution anyway.

Thanks again for your follow up boat_alexandra!

I have tried this. In fact, there were more generic ARCH=armhf config settings in the CMakeLists file prior to a big merge. These lines:

#IF (CMAKE_SYSTEM_PROCESSOR MATCHES "arm*")
#  SET (ARCH "armhf")
#ENDIF (CMAKE_SYSTEM_PROCESSOR MATCHES "arm*")

Were uncommented prior to this merge:
https://github.com/OpenCPN/OpenCPN/c...25668473202ea2

After this merge, the only way to set the ARCH=armhf was via distribution specific support.

Gentoo is a specifically supported distro, so I'm hoping to extract some of the specific build and config info from this:
https://packages.gentoo.org/package/...iences/opencpn

I'll dig here and see what I can extract.


As the project evolves, maybe distribution packaging can be partitioned out from core application source. Then the core application developers can more easily delegate the tasks of distribution packaging to others. This would make supporting different distributions more straightforward.

None of this is really OpenCPN's fault. The big complication here is the disaster that is accelerated graphics on the ARM platform in general, and RPi specifically. There are a collection of binary blob drivers with various capabilities. Open source acceleration in the X11 environment just doesn't really exist on RPi or other ARM platforms. It took decades of arm-twisting to reach the "pretty good" state of modern accelerated graphics on x86 (intel is very good). However with the transition to ARM, most of this progress in open sourcing graphic controller drivers, is thrown out the window and we're largely back in the dark ages.

OpenCPN is a great contribution to the boating and free software communities. These 2 "do it yourself" communities are a natural fit for each other, and opencpn is leading the charge.

I'll keep digging (as time allows) and will post any breakthroughs here.

Continued advice on the low level configuration of the RPi kernel drivers and X11 drivers to accommodate building OpenCPN is greatly appreciated.

Thanks to Everyone!

[seandepagnier]

Originally Posted by johnea

Hello,
As the project evolves, maybe distribution packaging can be partitioned out from core application source. Then the core application developers can more easily delegate the tasks of distribution packaging to others. This would make supporting different distributions more straightforward.

I didn't realize it wasn't until you posted. It should be.

None of this is really OpenCPN's fault. The big complication here is the disaster that is accelerated graphics on the ARM platform in general, and RPi specifically. There are a collection of binary blob drivers with various capabilities. Open source acceleration in the

Mostly accelerated graphics works with opengles on arm platform pretty well.

raspberry pi is an exception in that, both the old binary driver, and the new open source driver are still both unstable and buggy. This is really unfortunate, but as the raspberry pi is quickly becoming obsolete, hopefully it won't be an issue much longer.

Anything with mali graphics seems to work much better, for example, my odroid c2 worked about 10x faster than the raspberry pi 3, for opencpn. Unfortunately 1 drop of water killed it.

X11 environment just doesn't really exist on RPi or other ARM platforms. It took decades of arm-twisting to reach the "pretty good" state of modern accelerated graphics on x86 (intel is very good). However with the transition to ARM, most of this progress in open sourcing graphic controller drivers, is thrown out the window and we're largely back in the dark ages.

Yes, it wasn't until 2015 that the intel graphics was not also completely buggy.

OpenCPN is a great contribution to the boating and free software communities. These 2 "do it yourself" communities are a natural fit for each other, and opencpn is leading the charge.

I'll keep digging (as time allows) and will post any breakthroughs here.

Continued advice on the low level configuration of the RPi kernel drivers and X11 drivers to accommodate building OpenCPN is greatly appreciated.

Thanks to Everyone!

Basically, you can use opencpn with regular opengl and the fkms overlay. It works but eventually crashes in some cases.

A really unfortunate part is, without this overlay, and software opengl, also crashes. The software opengl is not stable either. I have been forced to use my raspberry without opengl recently as a result despite the fact that I added accelerated graphics to opencpn in the first place....

There are all sorts of new arm boards coming out the next year, in particular, ones with 6 processors (2ghz), 4 gb ram, usb 3, opengles (not buggy) and emmc. For about the price of raspberry pi was.

All of these features make them far superior to the raspberry.