I have run into an issue caused by the libtool configuration in the ganglia source build of 3.7.2 and am looking for some help.
My system has ganglia installed from the OS DVD in the default location. I also have a test build that I'm running from a separate location using the --prefix option passed to configure. In my test build, libtool is adding a -rpath option that prefers to find files in /usr/lib64 *before* looking in my install location which is not what I need since I've changed libganglia. This only is a problem if you have a libganglia.so* in both locations - which unfortunately my system has. Here is what a link looks like if you are curious: /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 ... -lpthread libtool: link: gcc -std=gnu99 ... -pthread -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/opt/ganglia_brent/lib64 I only saw one option about rpath in libtool, but modifying it didn't change things for the better. I attempted to dive into the code that actually constructed the rpath and quickly became confused. I was able to work around the problem by setting LDFLAGS during the configure phase, but it lead to the generation of the Makefiles taking multiple steps - once during the configure, and again during the first make. In case others are curious, here is what I did: % env LDFLAGS=-Wl,-rpath,/opt/ganglia_brent/lib64 ./configure --with-gmetad --prefix=/opt/ganglia_brent % make With this I'm off and running with the correct libraries, but I'm hoping there is a better way to address this issue. Any thoughts? thanks! brent ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
