>>> Jesse Becker <[EMAIL PROTECTED]> 11/29/2007 3:10 PM >>> >Brad Nicholes wrote: >> Correct. Both the gmond binary and the metric modules have to be running >> the same APR code in the same process. If both are statically linked to a >> libapr they would both have to initialize their own APR library, create >> their own memory pools, sockets, etc. They would not be able to share >> anything such as registering a module cleanup routine on a gmond owned >> memory pool. This is the reason why it was necessary to move to a >> dynamically loaded libapr for 3.1 and why --enable-static-build disables >> all of the loadable module functionality. The only way around it would be >> to not allow a loadable metric module to use any APR functions or be passed >> any APR created data. This would greatly restrict the functionality of a >> loadable module. So building ganglia 3.1.x statically no matter which >> version of APR you use, basically gets you ganglia 3.0.5. >> >> This doesn't discount the idea of delivering a separate tarball with that >> contains the external libraries, it just doesn't solve the dynamic vs >> static linking issue. > >There are two issues here: > 1) supporting statically compiled binaries > 2) having the library code in-tree or provided separately > >Static binaries are wonderful in some cases, and have saved my bacon a number >of times (although not with ganglia specifically). I've seen other projects >provide "-static" option that creates static libraries, based on whatever >versions are found. This could either replace, or be in addition to ->-enable-static-build (although the difference should be explained in the >configure --help options). >
I don't have a problem with leaving the --enable-static-build options as long as users understand what they are getting by statically linking. >Can the dynamically loaded metric modules could be statically linked? >Obviously, you lose the "dynamic" part, but would retain the ability to >monitor things. I've also heard that it is also possible to link some >libraries statically, but leave others dynamic. Perhaps that is also an >option? > This is a possibility. The Apache web server does this with it's modules. However this is where the autotools gurus really need to step up. The Apache configure script provides options such as --enable-modules=<module-list> and --enable-mods-shared=<module-list> to define a list of statically linked vs. dynamically linked modules. These options also take parameters such as "all" or "most" to specify whether all modules will be statically linked or dynamically linked rather than having to explicitly list them. It also provides an --enable-mod_whatever or --disable-mod_whatever to specify additional modules since they have a concept of a list of modules that are always enabled (ie built) vs those that aren't. You can tweak this list by either including them in one of the module list options or explicitly enabling or disabling the module. Take a look at the configure --help for the httpd server if my explanation doesn't make sense. All of this just depends on how much wo rk it takes to implement it and who is willing to step up and do the work. >If a separate tarball of apr/expat/confuse are provided, then I think it would >be appropriate to include a short bit of documentation along the lines of >"compile these three libraries as follows... Run the main ganglia ./configure >script with --foo and --bar to use them" agreed. Brad ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
