that message is entirely coming from glibc

pretty much every case where this comes up is because we're using `sudo` inside of an ebuild to hack around something we probably should be doing in a different way

Mike do you have an example of where this happens and how to fix it?

I am seeing it with xz-utils but am not sure what to change.

Also, how come this started happening? It didn't used to (TM)

you shouldn't be seeing it with xz-utils.  i don't.

Please see attached log. It's the FEATURES=test that does it, so perhaps it is expected? Does upstream play nicely with cross compiling?

Deleted: asc 454 KB

asc 454 KB View Download

trying to use FEATURES=test with emerge-$BOARD on arbitrary upstream packages is known to not work well (or at all).  you can test with the host sdk (sudo emerge foo) instead.

sjg: I have a current example:
https://uberchromegw.corp.google.com/i/chromeos/builders/daisy_spring-release/builds/2487/steps/UnitTest/logs/stdio

chromeos-ec-0.0.1-r3867: ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

This build is loaded with these "ERROR"s.

It doesn't really matter if FEATURES="test" is triggering this. As sheriff, when I look through a build log to find the actual failure, I don't want to have to figure out which ERRORs have been ignored.

Mike, what is the expected behaviour here? Is there a good way to remove these errors? If not, what is the least bad way?

from sandbox's POV, things are WAI.  for this particular bug, i think it's a diff issue from what Luigi raised here.  that output looks like the chromeos-ec is doing stuff it shouldn't ... for example, all those "skipping incompatible" messages suggests the build is messed up.  probably want to file a sep bug for chromeos-ec.

OK, I filed  crbug.com/728751  and am closing this one.

If in fact it affects other ebuilds, please feel free to reopen this.