+xzhou@ who implemented the proto stuff.

The rest of the platform code uses gyp instead of Make, so maybe that's what enables the other platform2 projects to use protoc.

That might be another alternative.

i don't think that's the reason for the error.  protoc/generate-chromeos-dbus-bindings are build time tools that we install in SDK.  we don't install them into the target board and we don't want to execute out of that.

The binary is indeed in the host but the target has the same shared libraries as the host installed as well. Therefore when executing in the target build directory, the binary picks the target libraries instead of the host and fails.

i.e. $ protoc works (Uses libraries from host)
     $ LD_LIBRARY_PATH=/build/$BOARD/usr/lib64 protoc fails because of mismatched symbols. 

we don't execute build time programs "in the target build directory".  no build should be setting LD_LIBRARY_PATH either.

there is a bashrc hack, but only for the src_test phase.
  https://chromium-review.googlesource.com/212784

the logs aren't loading there, so i can't check it further.

So IIUC, cheets-scripts should call  protoc/generate-chromeos-dbus-bindings more carefully i.e. without setting LD_LIBRARY_PATH etc.

cheets-scripts isn't setting LD_LIBRARY_PATH, the ebuild env hacks are

i talked with Xiaoyong while he was in town and suggested a few routes:
(1) fix the Makefile to not use dummy targets (look at chaps/Makefile as an example).  those are causing the generated protobuf files to be regenerated & recompiled all the time.  if that was fixed, then this issue would just go away as we wouldn't be running the tool in the first place during src_test.
(2) split the massive cheets ebuild up into multiple ebuilds.  it's currently doing a lot of unrelated things (compiling daemons, hacking squashfs files, installing init scripts, etc...).
(3) stop using custom Makefiles and convert to platform2 gyp files.  this would take care of a lot of things for you (like target management, build tests during src_compile, and executing tests in the target sysroot).
(4) move the code to the public platform2 to make it easier to re-use.

i think in the end he was interested in only doing (1) ;).

Thanks Mike for the update :-).

Bump to P1 since we want to migrate to libc++ soon. 
xzhou@ Can you take a look at this?

The proto files are not used for production right now. I didn't delete the files because xzhou@'s plan was to start using it soon in M65, but if this libc++ bug is urgent, one thing we could easily do for now is to stop building the proto files.

@manojgupta

I just talked with Luis and Yusukes, and it seems that moving to gyp is a better solution. I am not quite familiar with gyp. So it may take ~2 days, is this ok for you?

Yes, that's fine.

I have change the make file to gyy at: 
https://chrome-internal-review.googlesource.com/c/chromeos/cheets-scripts/+/523179

But I am not sure how to change the ebuild file to use the gyp. Currently, ebuild calls emake at:
https://cs.corp.google.com/chromeos_internal/src/private-overlays/project-cheets-private/chromeos-base/chromeos-cheets-scripts/chromeos-cheets-scripts-9999.ebuild?rcl=f135d3f09501251b626af8d7ebe24afa2eb6c1cf&l=240

Thanks a lot.

Discussed with hidehiko@ who is moving the spliting arc-setup and move it to platform2. It make more sense to apply http://crrev.com/i/523179 on top his CL once I receive it. 

CL: https://canary-chrome-internal-review.googlesource.com/c/chromeos/cheets-scripts/+/525899 should address this problem.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/cheets-scripts/+/e14a4e94e80b3ded6223b43cef01fb1d87109023

commit e14a4e94e80b3ded6223b43cef01fb1d87109023
Author: Hidehiko Abe <hidehiko@chromium.org>
Date: Wed Dec 13 20:33:34 2017

i believe this should be all set now by virtue of using platform2

C#19 solved the problem by removing calls to protoc in Makefile. There will be more CLs coming to separate arc-setup and move arc-setup to platform2.

Thanks for fixing this.