Good digging. Using that information, I was able to figure out why my build of the 0.7.0 tarball passed and yours didn't: I had libgflags installed via system package, and that's where glog was going to satisfy the dependency: adar@adar-ThinkPad-T540p:~/Source/kudu/build/debug$ ldd ./bin/protoc-gen-insertions | grep gflags libgflags.so.2 => /usr/lib/x86_64-linux-gnu/libgflags.so.2 (0x00007fbdb14a7000)
After I removed the package, protoc-gen-insertions failed the same way for me as it did for you. I'm using gold too, though my toolchain is probably newer than yours (gcc 5.2.1, binutils 2.25.1). For the time being I've worked around this by not using gold. On Tue, Feb 9, 2016 at 7:48 AM, Todd Lipcon <[email protected]> wrote: > 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 >
