>>> On 11/29/2007 at 3:32 PM, in message <[EMAIL PROTECTED]>, Carlo
Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 29, 2007 at 11:17:16AM -0700, Brad Nicholes wrote:
>> The reason why I am making that suggestion is because if somebody wants a
> static version then they should just c
>>> 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 l
On Thu, Nov 29, 2007 at 11:17:16AM -0700, Brad Nicholes wrote:
> The reason why I am making that suggestion is because if somebody wants a
> static version then they should just continue using 3.0.5.
They will also need the bugfixes we are getting into 3.1.x, and since we said
we won't maintain t
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 b
>>> On 11/29/2007 at 12:40 PM, in message <[EMAIL PROTECTED]>, Carlo
Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 29, 2007 at 10:26:57AM -0800, Bernard Li wrote:
>> In this case, static builds (with the updated dependencies from the
>> tarball) should be able to take advantage of t
On Thu, Nov 29, 2007 at 10:26:57AM -0800, Bernard Li wrote:
> In this case, static builds (with the updated dependencies from the
> tarball) should be able to take advantage of the new features?
No, you need to be linked with a dynamically loaded apr and had dlopen support
to be able to do that wh
Hi Brad:
On 11/29/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
> The reason why I am making that suggestion is because if somebody wants a
> static version then they should just continue using 3.0.5. They would be
> gaining nothing by building 3.1.x statically. Secondly, the static version
>
>>> On 11/29/2007 at 11:05 AM, in message <[EMAIL PROTECTED]>, Carlo
Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 29, 2007 at 09:52:14AM -0700, Brad Nicholes wrote:
>> I am seriously considering removing the --enable-static-build and the entire
> srclib tree since it is basically
Hi all,
My vote would be to never include external dependencies in the main
distribution, but that is not to say that a static build option should
be eliminated. Do any of the 3rd party dependencies lack a build system
to create both static and dynamic libraries? That's the only problem I
ca
On Thu, Nov 29, 2007 at 09:52:14AM -0700, Brad Nicholes wrote:
> I am seriously considering removing the --enable-static-build and the entire
> srclib tree since it is basically dead code going forward with 3.1.x.
>
> Thoughts?
don't you dare, --enable-static-build should be supported for anyone
On 11/29/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
> Here is a call for all of those autotools gurus out there to give the
> configure script a good run through. Especially on platforms other than
> Linux.
Hear hear!
P.S. I do not take any responsibilities for the hackery I have done to
co
Hi Brad:
On 11/29/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
> BTW, building trunk static essentially negates everything that has been done
> in trunk and leaves you with basically Ganglia 3.0.5. The major enhancement
> to 3.1.x is the ability to load metric modules which requires libapr1 to
>>> Jesse Becker <[EMAIL PROTECTED]> 11/29/2007 8:58 AM >>>
Carlo Marcelo Arenas Belon wrote:
> On Thu, Nov 29, 2007 at 09:56:14AM -0500, Jesse Becker wrote:
> if not using the python plugins then It would be probably easier to use the
> included libraries (specially considering that after OpenB
Carlo Marcelo Arenas Belon wrote:
On Thu, Nov 29, 2007 at 09:56:14AM -0500, Jesse Becker wrote:
I've been trying to build the trunk version of Ganglia on an OpenBSD 4.1
box recently, and it isn't for the faint of heart.
sadly true, building trunk isn't that easy if you are not using Fedora,
in
The configure script really needs a complete run through by somebody who is an
autotools guru. There are some other library dependancies that aren't being
picked up even on the linux platform. When I was building again yesterday on a
clean install of SLED, after running the configure script su
On Thu, Nov 29, 2007 at 09:56:14AM -0500, Jesse Becker wrote:
> I've been trying to build the trunk version of Ganglia on an OpenBSD 4.1
> box recently, and it isn't for the faint of heart.
sadly true, building trunk isn't that easy if you are not using Fedora,
indeed I didn't even though that do
I've been trying to build the trunk version of Ganglia on an OpenBSD 4.1 box
recently, and it isn't for the faint of heart. Rather, I should say that
debugging autoconf/automake foibles isn't for the faint of heart.
Background info:
OpenBSD 4.1 (release)
apr-1.2.7
libconfuse-2.5p0
automake (G
17 matches
Mail list logo
