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
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
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,
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 be
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
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
is
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 dead code
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
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 the new
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
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
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 continue
12 matches
Mail list logo
