PlanetaryImager icon indicating copy to clipboard operation
PlanetaryImager copied to clipboard

[BUG] Unable to build on RPi 4 running Raspbian Buster

Open andreok opened this issue 5 years ago • 3 comments

Describe the bug I'm getting the following error when trying to build PlanetaryImager from source on my RPi 4 running Raspbian Buster: "/usr/bin/ld: image_handlers/libfrontend_image_handlers.a(displayimage.cpp.o): undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0' /usr/bin/ld: //usr/lib/arm-linux-gnueabihf/libatomic.so.1: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: *** [src/CMakeFiles/planetary_imager_frontend.dir/build.make:243: src/planetary_imager_frontend] Error 1 make[1]: *** [CMakeFiles/Makefile2:351: src/CMakeFiles/planetary_imager_frontend.dir/all] Error 2 make: *** [Makefile:163: all] Error 2"

To Reproduce Steps to reproduce the behavior:

  1. clone PlanetaryImager git repo
  2. sudo apt -y install libatomic1
  3. install other dependencies
  4. cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DMAKE_PREFIX_PATH=/usr/lib/arm-linux-gnueabihf/cmake;/usr/share/OpenCV
  5. make all

Expected behavior Make targets should finish without errors, just like what happens for Planetary_imager_daemon target.

Screenshots My machine has libatomic.so.1.2.0

Desktop (please complete the following information):

  • OS: RPi 4 running Raspbian Buster
  • Application Version: git clone

Additional context I tried to make also the planetary_imager taget but the same error happens: "[100%] Linking CXX executable planetary_imager /usr/bin/ld: image_handlers/libfrontend_image_handlers.a(displayimage.cpp.o): undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0' /usr/bin/ld: //usr/lib/arm-linux-gnueabihf/libatomic.so.1: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[3]: *** [src/CMakeFiles/planetary_imager.dir/build.make:256: src/planetary_imager] Error 1 make[2]: *** [CMakeFiles/Makefile2:403: src/CMakeFiles/planetary_imager.dir/all] Error 2 make[1]: *** [CMakeFiles/Makefile2:415: src/CMakeFiles/planetary_imager.dir/rule] Error 2 make: *** [Makefile:275: planetary_imager] Error 2"

andreok avatar Nov 16 '19 21:11 andreok

I managed to fix the issue by following the steps described here: https://github.com/pytorch/pytorch/issues/22898 i.e.

  1. sudo apt-get install libatomics-ops-dev
  2. Change CMAKE_CXX_FLAGS variable in CMakeLists.txt file (in the main directory). i.e. add line set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -latomic")

andreok avatar Nov 16 '19 21:11 andreok

Got the following console output when testing with the command "src/planetary_imager --drivers .": "Starting PlanetaryImager - version 0.7.70 (armv7l) libEGL warning: DRI2: failed to authenticate qt5ct: using qt5ct plugin

(planetary_imager:9356): GLib-GObject-WARNING **: 18:54:43.734: cannot register existing type 'GtkWidget'

(planetary_imager:9356): GLib-GObject-CRITICAL **: 18:54:43.734: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(planetary_imager:9356): GLib-GObject-WARNING **: 18:54:43.734: cannot register existing type 'GtkBuildable'

(planetary_imager:9356): GLib-GObject-CRITICAL **: 18:54:43.734: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(planetary_imager:9356): GLib-CRITICAL **: 18:54:43.734: g_once_init_leave: assertion 'result != 0' failed

(planetary_imager:9356): GLib-GObject-CRITICAL **: 18:54:43.734: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(planetary_imager:9356): GLib-GObject-CRITICAL **: 18:54:43.735: g_type_register_static: assertion 'parent_type > 0' failed" and no window is displayed.

andreok avatar Nov 16 '19 22:11 andreok

I got the exact same thing, however in true linux style if you use sudo to run it it works fine.

You still get the “libEGL warning: DRI2: failed to authenticate” error but the other errors don’t appear if you use sudo. I read that the libEGL error can be fixed by building Qt5 from source, that will take days on a pi3 though.

I have to go into the configuration and cap the frame rate at 1s to stop it subsequently crashing when I use a camera though. The images from my camera are pretty big so it was just killing the pi trying to max out the frame rate.

I’m not sure I want to spend days building Qt to find out whether it will improve the performance or not. Especially as I mainly want to do time lapse so low frame rate isn’t an issue.

Igglebork avatar Dec 11 '19 22:12 Igglebork