Whoa!! Great find Haosong! Makes sense that it would be the source tarball since our environments are seemingly the same. I'll try this out this morning and let you know if I succeed. Thanks so much for your helping of a random stranger, I truly appreciate it!
- Erik On Sunday, July 12, 2015, haosdent <[email protected]> wrote: > Hi, Erik. The release package in > http://archive.apache.org/dist/mesos/0.22.1/mesos-0.22.1.tar.gz > contains m4/libtool.m4 while the > https://github.com/apache/mesos/archive/0.22.1.tar.gz don't contains > m4/libtool.m4. And use the m4/libtool.m4 (version is 2.4.6) in > http://archive.apache.org/dist/mesos/0.22.1/mesos-0.22.1.tar.gz would > append /usr/lib64 to rpath. But use your system libtool(version is 2.2.6), > would not append any rpath except you special it. > I still don't know why contains m4/libtool.m4 in release package, maybe > have some special reason. But for you, I think could use > https://github.com/apache/mesos/archive/0.22.1.tar.gz directly. > > On Sun, Jul 12, 2015 at 10:44 PM, haosdent <[email protected] > <javascript:;>> wrote: > > > Hi, Erik. I find the problem. The mesos-0.22.1.tar.gz( > > http://apache.cs.utah.edu/mesos/0.22.1/mesos-0.22.1.tar.gz) you provide > > have problems. Please download it from here( > > https://github.com/apache/mesos/archive/0.22.1.tar.gz). I could build it > > with correct rpath. > > > > On Sun, Jul 12, 2015 at 10:23 PM, haosdent <[email protected] > <javascript:;>> wrote: > > > >> The problem seems libtool generate in build directory are different. The > >> libtool mesos-0.22.1 used would append /usr/lib64 when link > libmesos.so. If > >> copy the libtool which generate under mesos master branch, would not > >> contains /usr/lib64 when link. > >> > >> On Sun, Jul 12, 2015 at 8:03 PM, haosdent <[email protected] > <javascript:;>> wrote: > >> > >>> Hi, Erik. I use 0.22.1 to build libmesos.so, could reproduce your > >>> problem. But use master branch, could not reproduce. > >>> > >>> > >>> On Sun, Jul 12, 2015 at 3:09 PM, Erik Weathers <[email protected] > <javascript:;>> > >>> wrote: > >>> > >>>> FYI, here's how I'm doing the build: > >>>> https://gist.github.com/erikdw/67db1eaeeeec4fb1ede8 > >>>> > >>>> I included the RPM list on the VM. > >>>> > >>>> - Erik > >>>> > >>>> > >>>> On Sat, Jul 11, 2015 at 11:35 PM, Erik Weathers < > [email protected] <javascript:;>> > >>>> wrote: > >>>> > >>>> > Thanks for bearing with me Haosong. > >>>> > > >>>> > No environment variable mucking with it that I can see. Only > >>>> potentially > >>>> > relevant thing is perhaps the LD_LIBRARY_PATH set by "scl": > >>>> > > >>>> > > >>>> > LD_LIBRARY_PATH=/opt/rh/devtoolset-2/root/usr/lib64:/opt/rh/devtoolset-2/root/usr/lib > >>>> > > >>>> > Regarding package versions, we are identical for those: > >>>> > automake-1.11.1-4.el6.noarch > >>>> > autoconf-2.63-5.1.el6.noarch > >>>> > libtool-2.2.6-15.5.el6.x86_64 > >>>> > > >>>> > Are you using scl with devtool-set2? > >>>> > > >>>> > I feel like the original suggestion you had won't yield different > >>>> behavior > >>>> > than my original LDFLAGS setting. i.e., my belief is that > >>>> "-Wl,-rpath=/usr/local/lib" > >>>> > is identical to "-Wl,-rpath,/usr/local/lib". I'm guessing these are > >>>> just > >>>> > syntax variants. > >>>> > > >>>> > It's worth reemphasizing that the mesos-slave, mesos-master, etc. > >>>> binaries > >>>> > have the RPATH set as I expect (the --prefix setting is sufficient > >>>> for that > >>>> > it). > >>>> > > >>>> > - Erik > >>>> > > >>>> > On Sat, Jul 11, 2015 at 11:24 PM, haosdent <[email protected] > <javascript:;>> > >>>> wrote: > >>>> > > >>>> >> My autotool version: > >>>> >> automake-1.11.1-4.el6.noarch > >>>> >> autoconf-2.63-5.1.el6.noarch > >>>> >> libtool-2.2.6-15.5.el6.x86_64 > >>>> >> > >>>> >> On Sun, Jul 12, 2015 at 2:23 PM, haosdent <[email protected] > <javascript:;>> > >>>> wrote: > >>>> >> > >>>> >> > I also use CentOS 6.5. > >>>> >> > > >>>> >> > On Sun, Jul 12, 2015 at 2:20 PM, haosdent <[email protected] > <javascript:;>> > >>>> wrote: > >>>> >> > > >>>> >> >> Does any exists environment variables affect your build? > >>>> >> >> > >>>> >> >> On Sun, Jul 12, 2015 at 2:16 PM, Erik Weathers < > >>>> [email protected] <javascript:;>> > >>>> >> >> wrote: > >>>> >> >> > >>>> >> >>> Thanks for the response Hao. Unfortunately that didn't work > for > >>>> me, > >>>> >> the > >>>> >> >>> default /usr/lib64 is inserted anyways. > >>>> >> >>> I'm building on CentOS 6.5, using the instructions for CentOS > 6.6 > >>>> >> here: > >>>> >> >>> http://mesos.apache.org/gettingstarted/ > >>>> >> >>> > >>>> >> >>> - Erik > >>>> >> >>> > >>>> >> >>> On Sat, Jul 11, 2015 at 10:08 PM, haosdent <[email protected] > <javascript:;>> > >>>> >> wrote: > >>>> >> >>> > >>>> >> >>> > Hi, @Erik I think you need to change > >>>> "-Wl,-rpath=/usr/local/lib" to > >>>> >> >>> > "-Wl,-rpath,/usr/local/lib". My build step: > >>>> >> >>> > > >>>> >> >>> > ``` > >>>> >> >>> > LDFLAGS="-Wl,-rpath,/usr/local/lib" ../configure > >>>> >> >>> > ``` > >>>> >> >>> > > >>>> >> >>> > And the result show the RPATH only contains /usr/local/lib > >>>> >> >>> > > >>>> >> >>> > ``` > >>>> >> >>> > $objdump -x ./src/.libs/libmesos.so |grep RPATH > >>>> >> >>> > RPATH /usr/local/lib > >>>> >> >>> > ``` > >>>> >> >>> > > >>>> >> >>> > On Sun, Jul 12, 2015 at 12:06 PM, Erik Weathers < > >>>> >> [email protected] <javascript:;> > >>>> >> >>> > > >>>> >> >>> > wrote: > >>>> >> >>> > > >>>> >> >>> > > hi mesos dev people, > >>>> >> >>> > > > >>>> >> >>> > > I'm hoping to enlist some help in building mesos such that > >>>> the > >>>> >> >>> > libmesos.so > >>>> >> >>> > > has its RPATH set as our environment expects. > Specifically, > >>>> in > >>>> >> our > >>>> >> >>> > > environment we install our own custom-built libraries under > >>>> >> >>> > /usr/local/lib, > >>>> >> >>> > > so I want the RPATH in the libmesos.so ELF to look like so: > >>>> >> >>> > > > >>>> >> >>> > > Library rpath: [/usr/local/lib:/usr/lib64] > >>>> >> >>> > > > >>>> >> >>> > > I've tried to effect this change by running configure like > >>>> so: > >>>> >> >>> > > > >>>> >> >>> > > LDFLAGS="-Wl,-rpath=/usr/local/lib" ./configure > >>>> >> >>> --prefix=/usr/local > >>>> >> >>> > > > >>>> >> >>> > > This resulted in the following RPATH being embedded in > >>>> >> libmesos.so: > >>>> >> >>> > > > >>>> >> >>> > > Library rpath: [/usr/lib64:/usr/local/lib] > >>>> >> >>> > > > >>>> >> >>> > > The RPATH *does* have /usr/local/lib, but I want that to be > >>>> the > >>>> >> 1st > >>>> >> >>> > entry, > >>>> >> >>> > > not the 2nd. I'm not familiar enough with autoconf nor > >>>> libtool to > >>>> >> >>> figure > >>>> >> >>> > > out how to get the order reversed. I *could* hack the > >>>> embedded > >>>> >> RPATH > >>>> >> >>> > with > >>>> >> >>> > > the chrpath tool, but I'd prefer changing build arguments > >>>> instead. > >>>> >> >>> > > > >>>> >> >>> > > I see in the g++ cmd that generates the .so that there are > >>>> >> includes > >>>> >> >>> of > >>>> >> >>> > > /usr/lib64 earlier than my passed LDFLAGS, so I wonder if > >>>> it's a > >>>> >> >>> > > configure.ac change I need to make to allow the LDFLAGS to > >>>> be > >>>> >> >>> shoved in > >>>> >> >>> > > front instead of behind the automatically generated > >>>> /usr/lib64 > >>>> >> >>> portion. > >>>> >> >>> > > > >>>> >> >>> > > Notably, simple use of the --prefix=/usr/local option > allows > >>>> the > >>>> >> >>> mesos-* > >>>> >> >>> > > binaries to have the embedded RPATH as I want, I'm only > >>>> struggling > >>>> >> >>> with > >>>> >> >>> > the > >>>> >> >>> > > libmesos.so RPATH. > >>>> >> >>> > > > >>>> >> >>> > > Thanks for whatever help you might provide! > >>>> >> >>> > > > >>>> >> >>> > > - Erik > >>>> >> >>> > > > >>>> >> >>> > > P.S., this is for building mesos-0.22.1 > >>>> >> >>> > > P.P.S., I tried --with-rpath=/usr/local/lib, but that > didn't > >>>> help > >>>> >> >>> either. > >>>> >> >>> > > > >>>> >> >>> > > >>>> >> >>> > > >>>> >> >>> > > >>>> >> >>> > -- > >>>> >> >>> > Best Regards, > >>>> >> >>> > Haosdent Huang > >>>> >> >>> > > >>>> >> >>> > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> -- > >>>> >> >> Best Regards, > >>>> >> >> Haosdent Huang > >>>> >> >> > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > -- > >>>> >> > Best Regards, > >>>> >> > Haosdent Huang > >>>> >> > > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Best Regards, > >>>> >> Haosdent Huang > >>>> >> > >>>> > > >>>> > > >>>> > >>> > >>> > >>> > >>> -- > >>> Best Regards, > >>> Haosdent Huang > >>> > >> > >> > >> > >> -- > >> Best Regards, > >> Haosdent Huang > >> > > > > > > > > -- > > Best Regards, > > Haosdent Huang > > > > > > -- > Best Regards, > Haosdent Huang >
