Thanks Todd, mind filing a jira as a blocker for 0.8.0? J-D
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 >
