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}
> 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?
-------------------------------------------------------------------------
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
