>>> On 4/30/2007 at 11:04 AM, in message <[EMAIL PROTECTED]>, Matt Massie <[EMAIL PROTECTED]> wrote:
>> Yes, the current makefiles will build a libexpat.so and install it in > /usr/lib. This is actually one thing that bothers me. > > that is actually not the case. if you look at the Makefile.am > in ./srclib you will find > > install: > echo > echo "Nothing from the srclib directory gets installed" > echo > If you look at the latest version of the Makefile.am, unfortunately this was one of the changes that I had to make to get dynamic linking working. :( Static linking libexpat won't work in this case because both libganglia.so and gmond both make expat calls (same with libconfuse). My guess is that static linking expat into both would case problems. If we want to continue distributing any external libraries, we probably need to install them to /opt/ganglia/lib to avoid collisions. Of course libexpat will go away when converted to apr-util, but if we continue to distribute apr, apr-util and libconfuse, we should think about installing them into /opt/ganglia. > i was very careful to make sure nothing in srclib get installed to avoid > that very thing you are concerned about: over-writing installed > software. > > the library are ./srclib are only used at compile time and not installed > anywhere. > > i also think moving to apr-util for XML parsing is a good idea. we do > need to keep in mind though that gmetad hasn't been moved over to libapr > yet and still needs expat. > > -matt Actually, if you build --with-libapr, gmetad will dynamically link to libapr1.so, libexpat.so and libganglia.so. The move to apr-util should cover everything all at once. Brad
