Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make run_assistant fails on Raspberry Pi #76

Open
jiiray opened this issue Aug 10, 2020 · 4 comments
Open

make run_assistant fails on Raspberry Pi #76

jiiray opened this issue Aug 10, 2020 · 4 comments

Comments

@jiiray
Copy link

jiiray commented Aug 10, 2020

I followed the setup instructions step by step on my Raspberry Pi and completed all the steps, except make run_assistant failing after a while with error:

In file included from src/assistant/json_util.cc:20:
./grpc/src/core/lib/json/json.h:30:10: fatal error: absl/strings/string_view.h: No such file or directory
 #include "absl/strings/string_view.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [<builtin>: src/assistant/json_util.o] Error 1

I see the missing abseil library is in the path ${GRPC_PATH}/third_party/abseil-cpp but makefile doesn't seem to find it? If I add line -I$(GRPC_SRC_PATH)/third_party/abseil-cpp to CPPFLAGS of the Makefile, I get declaration conflicts when trying to compile.

What might I have missed?

@Fleker
Copy link
Collaborator

Fleker commented Aug 10, 2020

You should check the version of gRPC you are using. In tests v1.11.0 has compiled fine.

@jiiray
Copy link
Author

jiiray commented Aug 10, 2020

I was in v1.12.1-12795-g9655f1f644. I cleaned the project and checked out v1.11.0 as in the build.sh you linked. Now ares building fails when I try to compile gRPC. I get following error:

third_party/cares/cares/ares_init.c: In function ‘ares_dup’:
third_party/cares/cares/ares_init.c:301:17: error: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]
           sizeof(src->local_dev_name)); 
                 ^
third_party/cares/cares/ares_init.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-invalid-source-encoding’ [-Werror]
cc1: all warnings being treated as errors
make: *** [Makefile:2782: /home/pi/Code/assistant-sdk-cpp/grpc/objs/opt/third_party/cares/cares/ares_init.o] Error 1

I didn't have same issue with the latest from the master. Could it have something to do with my GCC version? My current GCC version is gcc (Raspbian 8.3.0-6+rpi1) 8.3.0

@Fleker
Copy link
Collaborator

Fleker commented Aug 10, 2020

Potentially that version of gcc is too old.

@jiiray
Copy link
Author

jiiray commented Aug 11, 2020

By having more recent gRPC v1.22.0 as suggested here I managed to compile gRPC and also the assistant. How ever now I get segfault when trying to run any of the run_assistant_text, run_assistant_audio or run_assistant_file. Here's the backtrace:

$ seg_wrapper.sh ./run_assistant_text
/home/pi/seg_wrapper.sh: line 3: 16283 Segmentation fault      (core dumped) "$@"
Reading symbols from ./run_assistant_text...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 16283]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./run_assistant_text'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb6a4cde0 in google::protobuf::internal::AddDescriptors (table=0xb6b815e4 <descriptor_table_src_2fproto_2fgrpc_2freflection_2fv1alpha_2freflection_2eproto>) at google/protobuf/generated_message_reflection.cc:2375
2375	  if (*table->is_initialized) return;
#0  0xb6a4cde0 in google::protobuf::internal::AddDescriptors (table=0xb6b815e4 <descriptor_table_src_2fproto_2fgrpc_2freflection_2fv1alpha_2freflection_2eproto>) at google/protobuf/generated_message_reflection.cc:2375
#1  0xb6eeb2e8 in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0xbed8fb44, env=env@entry=0xbed8fb4c) at dl-init.c:72
#2  0xb6eeb3ec in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:30
#3  _dl_init (main_map=0xb6f0c978, argc=1, argv=0xbed8fb44, env=0xbed8fb4c) at dl-init.c:119
#4  0xb6edba74 in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Is there anything I can do here? I managed to get the Python version to work on the same computer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants