Figured out a few more clues on this: 1) I usually use gold rather than binutils ld as my linker. gold generates RUNPATH instead of RPATH by default, which has the difference that RUNPATH doesn't propagate transitively. In other words, even though protoc-gen-insertions has installed-deps/lib in its RUNPATH, it doesn't use _that_ RPATH when looking for dependencies of libglog.so, because libglog.so has its own RUNPATH. 2) my libglog.so's RUNPATH doesn't have installed-deps/. It turns out that, after I rebuilt my thirdparty from git completely clean, that one didn't end up with it either. It only got installed-deps/ in its RUNPATH before because I had an old 'libgflags.la' file lying around. 3) we no longer generate 'libgflags.la' from the gflags build after 7a68e1f8baee04eaf259f7567ddc39e09a0f0938 which switched from using autotools to cmake to build and install gflag. This means that we don't generate the libtool control file 'libgflags.la' anymore, though my old one got orphaned in the build directory.
If I switch back to binutils ld as my linker, everything seems fine. So, I think my takeaway is that the current state of master doesn't build with shared linking using gold. Since most _users_ will probably want to build release binaries (static-linked) anyway, and that works fine, I don't think this is a release blocker. We should try to figure it out and fix it in master, though, since it might hurt some developers (such as myself!) So, after that whole saga, I'm +1. Here's my detached signature for the release tarball: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEUEABECAAYFAla6CTgACgkQXkPKua7Hfq9e1wCeIEWC+t+rIjjPFFCbl1me1YPH DyIAlRM1FzuKIVQ1FEfJR9Bzk/QQrhQ= =WXqA -----END PGP SIGNATURE----- -Todd On Tue, Feb 9, 2016 at 1:28 AM, Todd Lipcon <[email protected]> wrote: > I think I narrowed down the issue a bit. In my release dir build, I have: > > todd@todd-ThinkPad-T540p:/tmp/apache-kudu-incubating-0.7.0/build/debug$ > objdump -x ../../thirdparty/installed-deps/lib/libglog.so | grep PATH > RUNPATH > /tmp/apache-kudu-incubating-0.7.0/thirdparty/installed/lib > > whereas in my working git checkout I have: > > todd@todd-ThinkPad-T540p:~/git/kudu/build/debug$ objdump -x > ../../thirdparty/installed-deps/lib/libglog.so | grep PATH > RUNPATH > > /home/todd/git/kudu/thirdparty/installed-deps/lib:/home/todd/git/kudu/thirdparty/installed/lib > > > I built the release using the 'build-support/jenkins/build-and-test.sh' > script. Somehow when this builds thirdparty in the context of the release > tarball, it ends up generating an incorrect rpath. Have to run to the first > ever Tokyo Kudu Meetup at the moment, but figured I'd dump state here in > case it rings a bell for anyone. The only thing I could think of is that > case where running clang from the wrong path can produce executables with > missing rpath elems, but not sure how that could be happening here (have no > clang on my path) > > On Mon, Feb 8, 2016 at 11:46 PM, Todd Lipcon <[email protected]> wrote: > >> hm, I was actually trying a debug build (shared linking) and hit the >> issue. Something odd with rpaths that I can't quite figure out. Building a >> release build seems to work OK here... I'll keep trying to investigate a >> bit before casting an official vote. >> >> On Mon, Feb 8, 2016 at 4:32 PM, Adar Dembo <[email protected]> wrote: >> >>> I've built the tarball on Ubuntu 15.10 and I didn't run into any issues. >>> Note that I'm using my system's cmake (3.2.2) and not the one in >>> thirdparty >>> (3.2.3). The commands I used: >>> - thirdparty/build-if-necessary.sh >>> - mkdir -p build/debug >>> - cd build/debug >>> - cmake ../.. >>> - make -j8 >>> >>> On Mon, Feb 8, 2016 at 3:43 PM, Todd Lipcon <[email protected]> wrote: >>> >>> > I'm building from the rc tarball here and hit this issue on Ubuntu >>> 14.04: >>> > >>> > >>> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions: >>> > error while loading shared libraries: libgflags.so.2: cannot open >>> shared >>> > object file: No such file or directory--insertions_out: >>> > protoc-gen-insertions: Plugin failed with status code 127. >>> > >>> /tmp/apache-kudu-incubating-0.7.0/build/debug/bin/protoc-gen-insertions: >>> > error while loading shared libraries: libgflags.so.2: cannot open >>> shared >>> > object file: No such file or directory >>> > >>> > ...which is odd because I can see libgflags.so in >>> > thirdparty/installed-deps/lib/ >>> > >>> > Anyone else seen the issue? Will dig into it more later today JP time, >>> but >>> > may be an rc-sinker. >>> > >>> > -Todd >>> > >>> > >>> > On Mon, Feb 8, 2016 at 10:21 AM, Jean-Daniel Cryans < >>> [email protected]> >>> > wrote: >>> > >>> > > Hi, >>> > > >>> > > We're happy to announce the first release candidate for Apache Kudu >>> > > (incubating) 0.7.0. >>> > > >>> > > The is a source-only release. The artifacts were staged here: >>> > > https://dist.apache.org/repos/dist/dev/incubator/kudu/0.7.0-RC1/ >>> > > >>> > > It was built from this tag: >>> > > >>> > > >>> > >>> https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=2e28d1aec47d86eba15b4ba3d8b40b34c410ca8a >>> > > >>> > > The list of all issues fixed is found following this link >>> > > < >>> > > >>> > >>> https://issues.cloudera.org/issues/?jql=project%20%3D%20Kudu%20AND%20status%20in%20 >>> > > >>> (Resolved)%20AND%20fixVersion%20%3D%200.7.0%20ORDER%20BY%20key%20ASC>. >>> > > >>> > > The release notes are found here (linking to github for prettier >>> > printing): >>> > > >>> > > >>> > >>> https://github.com/cloudera/kudu/blob/0.7.0-RC1/docs/release_notes.adoc#release-notes-specific-to-0-7-0 >>> > > >>> > > KEYS file: >>> > > http://www.apache.org/dist/incubator/kudu/KEYS >>> > > >>> > > I'd suggest going through the README, building Kudu, and running the >>> unit >>> > > tests. >>> > > >>> > > Please try the release and vote; vote will be open for at least 72 >>> hours. >>> > > >>> > > Thanks, >>> > > >>> > > J-D >>> > > >>> > >>> > >>> > >>> > -- >>> > Todd Lipcon >>> > Software Engineer, Cloudera >>> > >>> >> >> >> >> -- >> Todd Lipcon >> Software Engineer, Cloudera >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera > -- Todd Lipcon Software Engineer, Cloudera
