>>> On 3/12/2008 at 4:31 PM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Wed, Mar 12, 2008 at 02:20:45PM -0600, Brad Nicholes wrote: >> I think I am going to see some more clarification on this. >> --enable-static > doesn't seem to fit exactly with what we want to do. According to the > automake docs (http://sourceware.org/autobook/autobook/autobook_85.html), > --enable-static and --enable-shared deals with building static or dynamic > libraries rather than building a statically linked or dynamically linked > application. In our case what we are doing is building a statically linked > application. > > if libganglia is a static library, it will be linked statically with > gmond/gmetad/gmetric/gstat generating a statically linked application when > libtool builds the target (using -static). > > if all the other dependant libraries are also build statically, they will be > linked statically as well once they are located --with-${LIBRARY} >
This is where my confusion is. --enable-static does not mean build the application statically. What it means is produce a statically linkable library. In other words, I can define './configure --enable-static --enable-dynamic'. These two options are not mutually exclusive. What they mean is produce both a statically linkable and a dynamically linkable libraries. That is OK if we are talking about building libganglia only. However what we are talking about is building applications (gmond, gmetad, etc.). --enable-static as well as --enable-dynamic has no affect on how the gmond, gmetad, etc applications are linked to any other libraries. In looking around at other projects I have seen them use --enable-static-link or --enable-static-exec which have the same meaning as our --enable-static-build. >> The only thing that --enable-static would affect is whether to build >> libganglia > as a dynamic library or as a static library. It would have nothing to do > with the way gmond, gmetad, gstat or gexec are built. I think the question > here is do we want to continue to support static build (ie. > --enable-static-build) that produces standalone binaries? My vote would > be no, however if we decide to continue I think my original proposal is what > is needed. > > Removing support for static builds wasn't the question, but as I said in my > original post by removing the libraries in srclib we are making supporting > it > more difficult. > > Removing support to static binaries (which IMHO makes a lot of sense in HPC) > just because we can't deal with the complexities we impose in ourselves > shouldn't be an option. > > Carlo > > PS. I was waiting for a definition on confuse to proceed with removing it in > a > clean way (as done with expat) can we have a closure on that? > I think what I am saying is that we should dump libconfuse out of our SVN repository as well. I have everything working already as far as being able to build both statically and dynamically using the --enable-static-build configure option. I am all for dumping the static builds completely and therefore removing --enable-static-build. But I don't think that we can rework the static build around the --enable-static configure option. If you have a better or cleaner idea, I'm all for it. If you are also in favor of completely removing static builds, just let me know and I will have it ripped out in about 2 minutes. :) Brad ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
