to yunlian per llozano

It seems that the install_attributes-proto.install_attributes.pb.o is built with flag '-fPIE', so the error is expected.


The parameters is
['-MMD', '-MF', 'obj/common-mk/gen/include/bindings/install_attributes-proto.install_attributes.pb.o.d', '-D_LARGEFILE_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-Iobj/common-mk/install_attributes-proto.gen/include', '-Igen/include', '-I/build/amd64-generic/tmp/portage/chromeos-base/libbrillo-0.0.1-r367/work/libbrillo-0.0.1/platform2', '-I/build/amd64-generic/tmp/portage/chromeos-base/libbrillo-0.0.1-r367/work/libbrillo-0.0.1/platform', '-I/build/amd64-generic/usr/include', '-Wall', '-Wno-psabi', '-ggdb3', '-fstack-protector-strong', '-Wformat=2', '-fvisibility=internal', '-Wa,--noexecstack', '-Werror', '--sysroot=/build/amd64-generic', '-fPIE', '-std=gnu++11', '-DVCSID="0.0.1-r367-5c665a278204a485b426eaac52e20938d2be5739"', '-D_FILE_OFFSET_BITS=64', '-D_LARGEFILE_SOURCE', '-D_LARGEFILE64_SOURCE', '-O2', '-pipe', '-O2', '-pipe', '-O2', '-pipe', '-march=x86-64', '-msse3', '-g', '-fno-exceptions', '-fno-unwind-tables', '-fno-asynchronous-unwind-tables', '-clang-syntax', '-fsanitize=address', '-fsanitize=alignment', '-fsanitize=shift', '-clang-syntax', '-fno-exceptions', '-fno-unwind-tables', '-fno-asynchronous-unwind-tables', '-c', 'gen/include/bindings/install_attributes.pb.cc', '-o', 'obj/common-mk/gen/include/bindings/install_attributes-proto.install_attributes.pb.o']

+derat, +vapier

yunlian, are you saying that something is wrong with the build config for this libbrillo target?

I'm not sure where the canonical source is for that package. I see code in aosp/external/libbrillo but it hasn't changed since October 24, 2016.

compiler changed. SO the compiler maybe more strict now. 
We are still looking into the root cause.

#4: Yes, aosp/external/libbrillo is where the source is located. I don't see any changes since October either, so it seems likely that something else triggered the failure.

while something prob has changed in compiler land to happen to push the executable layout over the edge of the smaller reloc limits, this is still a bug in the build side.  namely, we're pulling in static_library objects that are being built with -fPIE into a shared library.

i'm not sure if there is an easy way to pull this off in gyp.  we can go two routes:
(1) change all of the proto targets in common-mk/external_dependencies.gyp to build explicitly with -fPIC (and remove -fPIC).  this should work in all cases (shared/static/executable), but has the downside of being somewhat larger/slower (although i haven't measured the actual delta here binary-wise).
(2) duplicate the proto targets in common-mk/external_dependencies.gyp when we want to use them in a shared lib, give it a name with like a "-shared" suffix, and have that use -fPIC instead of -fPIE.  the downside here is we have to duplicate the build rules for these proto files.  we can add a gyplint check to make sure though that we don't mix shared/static/executable targets incorrectly.

Yes, I think the new rolled compiler trigger the bug.

Assign it to vapier for now since he is on the OWNERS list.
Is that OK?

Can someone take a look at this today? The bot has been failing since Monday. Failures are the same as in #1.

https://build.chromium.org/p/chromiumos/builders/amd64-generic-asan

Adding gardeners from this week to assist in fixing this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/5e9e5458fc11130cb0e969602b40331cec9a7050

commit 5e9e5458fc11130cb0e969602b40331cec9a7050
Author: Yunlian Jiang <yunlian@google.com>
Date: Thu Feb 02 04:27:52 2017

common-mk: use '-fPIC' for install_attributes-proto.a

install_attributes-proto.a is linked into a shared library, so we
should build it with -fPIC instead of -fPIE.

BUG= chromium:685313 
TEST=emerge-amd64-generic libbrillo passes.

Change-Id: I1ccd1bf24dd0ef376a18394a214f9ba1938de7cc
Reviewed-on: https://chromium-review.googlesource.com/434807
Commit-Ready: Yunlian Jiang <yunlian@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/5e9e5458fc11130cb0e969602b40331cec9a7050/common-mk/external_dependencies.gyp

I guess the original problem got fixed and a new failure is happening.

chaps-0.0.1-r1785: [1/2] SOLINK lib/libchaps.so
chaps-0.0.1-r1785: FAILED: lib/libchaps.so lib/libchaps.so.TOC 
chaps-0.0.1-r1785: if [ ! -e lib/libchaps.so -o ! -e lib/libchaps.so.TOC ]; then flock linker.lock x86_64-cros-linux-gnu-clang++ -shared -Wl,-O1 -Wl,-O2 -Wl,--as-needed -fsanitize=address -fsanitize=alignment -fsanitize=shift -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,now -Wl,--as-needed --sysroot=/build/amd64-generic -pthread -o lib/libchaps.so -Wl,-soname=libchaps.so -Wl,--whole-archive obj/chaps/libchaps.attributes.o obj/chaps/libchaps.chaps.o obj/chaps/libchaps.chaps_proxy.o obj/chaps/libchaps.chaps_utility.o obj/chaps/libchaps.isolate_chromeos.o obj/chaps/libchaps.token_manager_client.o obj/chaps/libchaps-protos.a  -Wl,--no-whole-archive -ldbus-c++-1 -ldbus-1 -lprotobuf-lite -lpthread -lssl -lcrypto -lbrillo-395517 -lbase-395517 && { readelf -d lib/libchaps.so | grep SONAME ; nm -gD -f p lib/libchaps.so | cut -f1-2 -d' '; } > lib/libchaps.so.TOC; else flock linker.lock x86_64-cros-linux-gnu-clang++ -shared -Wl,-O1 -Wl,-O2 -Wl,--as-needed -fsanitize=address -fsanitize=alignment -fsanitize=shift -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,now -Wl,--as-needed --sysroot=/build/amd64-generic -pthread -o lib/libchaps.so -Wl,-soname=libchaps.so -Wl,--whole-archive obj/chaps/libchaps.attributes.o obj/chaps/libchaps.chaps.o obj/chaps/libchaps.chaps_proxy.o obj/chaps/libchaps.chaps_utility.o obj/chaps/libchaps.isolate_chromeos.o obj/chaps/libchaps.token_manager_client.o obj/chaps/libchaps-protos.a  -Wl,--no-whole-archive -ldbus-c++-1 -ldbus-1 -lprotobuf-lite -lpthread -lssl -lcrypto -lbrillo-395517 -lbase-395517 && { readelf -d lib/libchaps.so | grep SONAME ; nm -gD -f p lib/libchaps.so | cut -f1-2 -d' '; } > lib/libchaps.so.tmp && if ! cmp -s lib/libchaps.so.tmp lib/libchaps.so.TOC; then mv lib/libchaps.so.tmp lib/libchaps.so.TOC ; fi; fi
chaps-0.0.1-r1785: /usr/x86_64-pc-linux-gnu/x86_64-cros-linux-gnu/binutils-bin/2.25.51/ld.gold.real: error: obj/chaps/libchaps-protos.a(obj/chaps/gen/include/chaps/proto_bindings/chaps-protos.attributes.pb.o): requires dynamic R_X86_64_PC32 reloc against '_ZSt9make_pairIRjbESt4pairINSt17__decay_and_stripIT_E6__typeENS2_IT0_E6__typeEEOS3_OS6_' which may overflow at runtime; recompile with -fPIC
chaps-0.0.1-r1785: /usr/x86_64-pc-linux-gnu/x86_64-cros-linux-gnu/binutils-bin/2.25.51/ld.gold.real: error: obj/chaps/libchaps-protos.a(obj/chaps/gen/include/chaps/proto_bindings/chaps-protos.attributes.pb.o): requires dynamic R_X86_64_PC32 reloc against '_ZSt4swapIPSsEvRT_S2_' which may overflow at runtime; recompile with -fPIC
chaps-0.0.1-r1785: clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)

same reason with same fix -- chaps-protos in chaps.gyp needs to use -fPIC

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/8025358fae0cb2de56895dbc5b33ff940c19cf34

commit 8025358fae0cb2de56895dbc5b33ff940c19cf34
Author: Yunlian Jiang <yunlian@google.com>
Date: Tue Feb 07 00:40:57 2017

chaps: use '-fPIC' for libchaps-protos.a

libchaps-protos.a is linked into a shared library, so we
should build it with -fPIC instead of -fPIE.

BUG= chromium:685313 
TEST=emerge-amd64-generic libbrillo passes.

Change-Id: I144e5ff33863bd5f8cd64486599e9d097bb44832
Reviewed-on: https://chromium-review.googlesource.com/437624
Commit-Ready: Yunlian Jiang <yunlian@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/8025358fae0cb2de56895dbc5b33ff940c19cf34/chaps/chaps.gyp

The issue is fixed on the bots. Is this fully addressed?

Yes, the bot has been green for 3 days.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/85a93a62bd711a45a5d9876d949fcb5d86b43bff

commit 85a93a62bd711a45a5d9876d949fcb5d86b43bff
Author: Mike Frysinger <vapier@chromium.org>
Date: Fri Oct 13 21:45:21 2017

common-mk: gyplint: check for static/shared lib linkage

We build static libs as PIEs with the assumption that they only get
used in standalone programs (which are also PIEs).  This is normally
fine.  But when someone tries to link a static lib into a shared lib,
it can fail due to the slight PIC-vs-PIE differences.  Add a gyplint
check to catch this whenever possible.

BUG= chromium:685313 
TEST=gyplint correctly flags hammerd

Change-Id: Ie80aaddf5a0d26675f5413bcedb6672619e4e8b2
Reviewed-on: https://chromium-review.googlesource.com/703414
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/85a93a62bd711a45a5d9876d949fcb5d86b43bff/common-mk/gyplint.py
[modify] https://crrev.com/85a93a62bd711a45a5d9876d949fcb5d86b43bff/common-mk/gyplint_unittest.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/2b4dfe8675acf43dd3d9491e6d614408977577e3

commit 2b4dfe8675acf43dd3d9491e6d614408977577e3
Author: Chih-Yu Huang <akahuang@google.com>
Date: Fri Oct 13 21:45:26 2017

hammerd: add static lib flag.

In CL:703414 we check whether the static library is used by shared
library. If so, we should use PIC flag instead of PIE. This CL adds
the flag in hammerd.gyp.

BUG= chromium:685313 
TEST=common-mk/gyplint.py hammerd/hammerd.gyp

Change-Id: Iecb1d28a33230850d1eb7eec4020062ea1d112c1
Reviewed-on: https://chromium-review.googlesource.com/711735
Commit-Ready: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/2b4dfe8675acf43dd3d9491e6d614408977577e3/hammerd/hammerd.gyp