The problem with that is that it turns off static libraries for the entire
project including building libganglia.la which is a legitimate library. We
need it to build the libganglia.la static library along with the module DSOs.
Its just that the .a and .la static libraries that are produced al
Hi Matt:
This would disable for both libganglia & libmodexample though -- is
this the behaviour we want for RPM creation?
Thanks,
Bernard
On 4/6/07, Matt Massie <[EMAIL PROTECTED]> wrote:
if you don't want static libraries... configure ganglia with
--disable-static
... i think that might wo
if you don't want static libraries... configure ganglia with
--disable-static
... i think that might work.
On Fri, 2007-04-06 at 10:16 -0600, Brad Nicholes wrote:
> >>> On 4/5/2007 at 9:46 AM, in message
> <[EMAIL PROTECTED]>, "Bernard Li"
> <[EMAIL PROTECTED]> wrote:
> > Hi Brad:
> >
> > On 4
Hi Brad:
Thanks for looking into it.
I have already updated the spec file, so that libmodexample* will be
included with ganglia-gmond package.
Let's hope someone could help us fix this :-)
Cheers,
Bernard
On 4/6/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>>> On 4/5/2007 at 9:46 AM, in mes
>>> On 4/5/2007 at 9:46 AM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Hi Brad:
>
> On 4/5/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>
>> Actually the .a and .la files don't need to be delivered at all. They
> should be marked in the make file as not part of th
Hi Brad:
On 4/5/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
Actually the .a and .la files don't need to be delivered at all. They should
be marked in the make file as not part of the distribution. The .so.0.0.0 file
is the loadable module that produces a metric (the others are symlinks).
>>> On Wed, Apr 4, 2007 at 11:07 PM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Got another error while building on x86_64 hosts:
>
[...]
> protocol_xdr.c: At top level:
> protocol_xdr.c:194: warning: initialization makes integer from pointer
> without a cast
> pr
>>> On Wed, Apr 4, 2007 at 10:30 PM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Hi Brad:
>
> I'm trying to build RPMs for Ganglia trunk and I got the following errors:
>
> Checking for unpackaged file(s): /usr/lib/rpm/check- files
> /tmp/ganglia- 3.0.5.200704042059
Got another error while building on x86_64 hosts:
bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..
-I.. -I. -I../srclib/expat/lib/ -I../libmetrics/
-I../srclib/apr/include/ -I../srclib/apr/include/arch/unix/
-I../srclib/confuse/src -O2 -g -Wall -D_REENTRANT -c -o
protocol_xdr.lo
Hi Brad:
I'm trying to build RPMs for Ganglia trunk and I got the following errors:
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/tmp/ganglia-3.0.5.200704042059-buildroot
error: Installed (but unpackaged) file(s) found:
/usr/lib/libmodexample.a
/usr/lib/libmodexample.la
/usr/l
>>> On 4/2/2007 at 11:49 AM, in message
<[EMAIL PROTECTED]>, Matt Massie
<[EMAIL PROTECTED]> wrote:
> On Mon, 2007-04-02 at 11:00 -0600, Brad Nicholes wrote:
>
>> Is there a reason why you created the 3.0.x development branch in ./tags?
>
> because i goof'd. i just moved the monitor-core-3.0-b
On Mon, 2007-04-02 at 11:00 -0600, Brad Nicholes wrote:
> Is there a reason why you created the 3.0.x development branch in ./tags?
because i goof'd. i just moved the monitor-core-3.0-beta branch out of
"tags" and into "branches". sorry for the sloppiness...
> Unless you see any reason not t
>>> On 4/1/2007 at 10:05 AM, in message
<[EMAIL PROTECTED]>, Matt Massie
<[EMAIL PROTECTED]> wrote:
> i just added brad to the list of developers with write access to our
> subversion repository. welcome to the team, brad!
>
Thanks, I really appreciate the vote of confidence. Hopefully the enha
Hi Matt,
--- Matt Massie <[EMAIL PROTECTED]> wrote:
> i just added brad to the list of developers with write access to our
> subversion repository. welcome to the team, brad!
>
let me join you to welcome Brad to the crowd. His work looks exciting
and needs to go in.
> i've created a branch ca
i just added brad to the list of developers with write access to our
subversion repository. welcome to the team, brad!
i've created a branch called "monitor-core-3.0-beta" for 3.0.x
development from what is currently in trunk. we might not need quite as
rigorous a process as apache but i think w
>>> On 3/26/2007 at 9:38 AM, in message
<[EMAIL PROTECTED]>, Martin Knoblauch
<[EMAIL PROTECTED]> wrote:
> Hi Brad,
>
> for the extensibility stuff, I believe we have not yet decided how to
> proceed:
>
> - put it in 3.0 - only possible if it does not break compatibility with
> existing gmond da
TED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Brad Nicholes
> Sent: 26 March 2007 16:20
> To: matt massie; Brad Nicholes
> Cc: ganglia-developers@lists.sourceforge.net
> Subject: Re: [Ganglia-developers] Adding extensibility to gmond...
>
>
> >>> On 3/1/2007 at 1
Hi Brad,
for the extensibility stuff, I believe we have not yet decided how to
proceed:
- put it in 3.0 - only possible if it does not break compatibility with
existing gmond datastreams. We are very careful here.
- branch of 3.1 - needed when the core metrics array is changed
- branch of 4.0 -
please send me your sourceforge account name and i'll immediately give
you access to subversion.
-matt
On Mon, 2007-03-26 at 09:20 -0600, Brad Nicholes wrote:
>>> On 3/1/2007 at 1:49 PM, in message <[EMAIL PROTECTED]>, "Brad
Nicholes" <[EMAIL PROTECTED]> wrote:
> All,
> I have just added an enhancement request to bugzilla (#129) for adding
> modular metric extensibility to gmond. I have also attached a patch file and
> example module to the bug re
>>> On 3/1/2007 at 1:49 PM, in message <[EMAIL PROTECTED]>, "Brad
Nicholes" <[EMAIL PROTECTED]> wrote:
> All,
> I have just added an enhancement request to bugzilla (#129) for adding
> modular metric extensibility to gmond. I have also attached a patch file and
> example module to the bug re
Rich,
this is actually where I see the future direction for gmond - having
all metrics configurable.
But if ysou do this you may end up with slightly different "gmonds".
We need to find a way to make those work together seamlessly.
Cheers
Martin
--- Richard Mohr <[EMAIL PROTECTED]> wrote:
> O
On Fri, 2007-03-02 at 12:17 -0700, Brad Nicholes wrote:
> It would depend on whether you wanted to repeat the path info
> throughout the .conf file. I would still suggest that you have a
> modules{} section for loading the metrics modules and then use the
> metric{} sections for defining how
>>> On 3/2/2007 at 10:13 AM, in message <[EMAIL PROTECTED]>, Richard
Mohr <[EMAIL PROTECTED]> wrote:
> OK. Maybe I should have looked at Brad's patch before putting in my
> $0.02 :-)
>
> It seems like his patch is already doing much of what I suggested. But
> personally, I think we should go ev
>>> On 3/2/2007 at 8:40 AM, in message
<[EMAIL PROTECTED]>, Martin Knoblauch
<[EMAIL PROTECTED]> wrote:
> Brad,
>
> thanks for providing this functionality. As others already commented,
> this is urgently needed.
>
> Now we have the question how to move on. It seems to me that we are on
> the w
OK. Maybe I should have looked at Brad's patch before putting in my
$0.02 :-)
It seems like his patch is already doing much of what I suggested. But
personally, I think we should go even farther and make every metric a
dynamically loaded metric. These types of lines should be completely
banish
On Fri, 2007-03-02 at 07:40 -0800, Martin Knoblauch wrote:
> My vision for the future would include a completely configurable set
> of core metrics for "gmond". But in a way where different gmonds still
> can work together in some meaningfull way.
>
> For example we have to rework the metrics a
PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Martin Knoblauch
Sent: Friday, March 02, 2007 3:41 PM
To: Brad Nicholes; matt massie
Cc: ganglia-developers@lists.sourceforge.net
Subject: Re: [Ganglia-developers] Adding extensibility to gmond...
Brad,
thanks for providing this functionality. As other
Brad,
thanks for providing this functionality. As others already commented,
this is urgently needed.
Now we have the question how to move on. It seems to me that we are on
the way of opening 3.1 or 4.0.
My vision for the future would include a completely configurable set
of core metrics for "
All,
I have just added an enhancement request to bugzilla (#129) for adding
modular metric extensibility to gmond. I have also attached a patch file and
example module to the bug report that add this functionality. Hopefully you
will find this enhancement useful and commit it to the gangli
On Tuesday 27 February 2007 17:28, Brad Nicholes wrote:
> [...] When I am finished, it will probably work similar to data gathered
> through gmetric.
Yes, indeed.
In fact, one could have one of the DSO objects expose this interface via a
UNIX-socket (for example). Then, gmetric simply punt to
>>> Paul Millar <[EMAIL PROTECTED]> 2/27/2007 10:36 AM >>>
On Tuesday 27 February 2007 16:36, Brad Nicholes wrote:
>>I am working on adding metric module extensibility to gmond ...
>
>Hi Brad,
>
>As an aside, does MonAMI do any of the things you want?
>http://monami.sourceforge.net/
>
>.It c
On Tuesday 27 February 2007 16:36, Brad Nicholes wrote:
>I am working on adding metric module extensibility to gmond ...
Hi Brad,
As an aside, does MonAMI do any of the things you want?
http://monami.sourceforge.net/
It can route information to Ganglia (and has support for a number o
Sounds good. I have the extensibility functionality at the point where I am
able to define, build and load a module that implements a metric. A simple
preliminary example of what the source for a module looks like is attached. As
noted in the example source, I think that the module could b
brad-
having loadable modules for gmond would be outstanding. one of the
reason i moved gmond onto apr was for that very reason.
there is no real reason for gmond to statically linked. it is mostly a
historical artifact really. when ganglia was first written (back in
2000), package managemen
I am working on adding metric module extensibility to gmond in much the same
way that Apache loads and uses dynamic modules. The fact that APR already
support DSO loading for various platforms, makes the Apache model an easy fit.
While implementing the example metric module, I wondered why
36 matches
Mail list logo
