Re: [Ganglia-developers] [Ganglia-general] Ganglia 3.1.4 beta ready for testing
On Tue, Oct 27, 2009 at 09:52:52AM +, Paul Sobey wrote: /usr/include/sys/feature_tests.h:336:2: error: #error Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99 make[2]: *** [getopt1.o] Error 1 Googling leads me to try compiling with CFLAGS=-std=gnu99 per: http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=215 this is a bug on the autoconf from CentOS 4 which is used to build the release packages, therefore you can also workaround the issue by rebootstrapping the package or making your own with a better version of the autotools. for simplicity I'd uploaded an unofficial release package for 3.1.4 bootstrapped on fedora rawhide in : http://sajino.sajinet.com.pe/ganglia/ganglia-3.1.4.tar.gz If do that, compilation fails building against Python 2.6.2 (built with same toolchain): once you use -std=gnu99 is no longer the same toolchain and therefore building python with the same standard support should solve your problem. Carlo -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [Ganglia-general] Ganglia 3.1.4 beta ready for testing
Hi Carlo: On Thu, Oct 29, 2009 at 12:01 PM, Carlo Marcelo Arenas Belon care...@sajinet.com.pe wrote: this is a bug on the autoconf from CentOS 4 which is used to build the release packages, therefore you can also workaround the issue by rebootstrapping the package or making your own with a better version of the autotools. for simplicity I'd uploaded an unofficial release package for 3.1.4 bootstrapped on fedora rawhide in : http://sajino.sajinet.com.pe/ganglia/ganglia-3.1.4.tar.gz Do you have a link for the bug, and are you aware whether there are updates for CentOS 4 to fix the issue? I guess I could start building on CentOS 5, provided that the autoconf does not have this bug. Thanks, Bernard -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [Ganglia-general] Ganglia 3.1.4 beta ready for testing
On Thu, Oct 29, 2009 at 04:44:59PM +, Paul Sobey wrote: I note from the Makefile Daniel posted: # Depends: some issues exist getting the Python support working on Solaris, # Ganglia's configure.in needs to be further enhanced for this to work I think this is a CSW specific problem, as I had no problem getting python support compiled in Solaris 10u7 x86 using SUNWPython-devel, SUNWgcc, SUNWlexpt and compiled versions of confuse and apr. $ PATH=$PATH:/usr/sfw/bin:/usr/ccs/bin $ ./configure CC=gcc -std=gnu99 --prefix=/usr/local --with-libarp=/usr/local/apr/bin/apr-1-config --with-libconfuse=/usr/local $ make Daniel, could you elaborate? Carlo -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [Ganglia-general] Ganglia 3.1.4 beta ready for testing
Carlo Marcelo Arenas Belon wrote: On Thu, Oct 29, 2009 at 04:44:59PM +, Paul Sobey wrote: I note from the Makefile Daniel posted: # Depends: some issues exist getting the Python support working on Solaris, # Ganglia's configure.in needs to be further enhanced for this to work I think this is a CSW specific problem, as I had no problem getting python support compiled in Solaris 10u7 x86 using SUNWPython-devel, SUNWgcc, SUNWlexpt and compiled versions of confuse and apr. $ PATH=$PATH:/usr/sfw/bin:/usr/ccs/bin $ ./configure CC=gcc -std=gnu99 --prefix=/usr/local --with-libarp=/usr/local/apr/bin/apr-1-config --with-libconfuse=/usr/local $ make Daniel, could you elaborate? Although I have described the Python module in the CSW Makefile, it is not something I have properly tested, I am still working through some core agent problems (e.g. see the discussion on csw-maintainers about building a 64 bit version of everything: I've noticed that when running a 32 bit binary on some 64 bit machines with lot's of RAM, some kstat calls lead to a seg fault) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [Ganglia-general] Ganglia 3.1.4 beta ready for testing
On Thu, Oct 29, 2009 at 08:42:05PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Thu, Oct 29, 2009 at 04:44:59PM +, Paul Sobey wrote: I note from the Makefile Daniel posted: # Depends: some issues exist getting the Python support working on Solaris, # Ganglia's configure.in needs to be further enhanced for this to work Daniel, could you elaborate? Although I have described the Python module in the CSW Makefile, it is not something I have properly tested. OK and I haven't done any testing either, other than making sure it builds and that a mod_example like module can be loaded, but my question was more about the need to change configure.in to support python modules which you were referring about in the Makefile as Paul noted. I am still working through some core agent problems (e.g. see the discussion on csw-maintainers about building a 64 bit version of everything: I've noticed that when running a 32 bit binary on some 64 bit machines with lot's of RAM, some kstat calls lead to a seg fault) care to provide a link to the thread or any bug reports?, earlier releases for 3.0 required 64bit binaries as they were reading kernel memory directly to gather the statistics, but after those metrics were migrated to kstat that shouldn't be an issue anymore, and I am running some 32-bit 3.0 agent with solaris sparc with significant amount of memory as well, so there might be a regression to track here. Carlo -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [Ganglia-general] Ganglia 3.1.4 beta ready for testing
Carlo Marcelo Arenas Belon wrote:
On Thu, Oct 29, 2009 at 08:42:05PM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
On Thu, Oct 29, 2009 at 04:44:59PM +, Paul Sobey wrote:
I note from the Makefile Daniel posted:
# Depends: some issues exist getting the Python support working on
Solaris,
# Ganglia's configure.in needs to be further enhanced for this to work
Daniel, could you elaborate?
Although I have described the Python module in the CSW Makefile, it is
not something I have properly tested.
OK and I haven't done any testing either, other than making sure it builds
and that a mod_example like module can be loaded, but my question was more
about the need to change configure.in to support python modules which you
were referring about in the Makefile as Paul noted.
I definitely remember playing with configure.in to try and get the
Python support working with CSW, although I'm not certain what state I
left it in.
I've done a diff from 2017:HEAD on trunk/configure.in, it appears that
none of my changes for Python support on Solaris are in there.
In one branch I started working on I tried setting up my own LDFLAGS for
Python, e.g. in configure.in:
LDFLAGS_PYTHON=-lpython${PY_VERSION}
or for static:
LDFLAGS_PYTHON=/opt/csw/lib/python2.3/config/libpython${PY_VERSION}.a -lm
and using LDFLAGS_PYTHON with when linking the Python module.
However, I don't think this is best practice for configure.in. I can
have a go at making it work, but it would be useful to agree on the
compatibility requirements first: e.g. should compatibility with
CSWpython be the main goal, or do we want to set some other criteria?
I am still working through some
core agent problems (e.g. see the discussion on csw-maintainers about
building a 64 bit version of everything: I've noticed that when running
a 32 bit binary on some 64 bit machines with lot's of RAM, some kstat
calls lead to a seg fault)
care to provide a link to the thread or any bug reports?, earlier releases
for 3.0 required 64bit binaries as they were reading kernel memory directly
to gather the statistics, but after those metrics were migrated to kstat
that shouldn't be an issue anymore, and I am running some 32-bit 3.0 agent
with solaris sparc with significant amount of memory as well, so there
might be a regression to track here.
I've been discussing the issue privately with Dago, it is easily
reproducible on the host called build8st in the CSW build farm. All my
latest packages are on the box already so if you request an account, you
can try it. I'll forward you the email.
The more general discussion on building packages containing both 32 and
64 bit libraries started here:
http://lists.opencsw.org/pipermail/maintainers/2009-October/004687.html
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] Solaris support for 3.1.4 (Was RE: Ganglia 3.1.4 beta ready for testing)
Trimming CC and changing Subject to better focus this thread
On Thu, Oct 29, 2009 at 10:09:32PM +, Daniel Pocock wrote:
Carlo Marcelo Arenas Belon wrote:
my question was more
about the need to change configure.in to support python modules which you
were referring about in the Makefile as Paul noted.
I definitely remember playing with configure.in to try and get the
Python support working with CSW, although I'm not certain what state I
left it in.
do you mean you have a modified 3.1 package that had extensions for CSW
python support?, are those modifications available somewhere?
I've done a diff from 2017:HEAD on trunk/configure.in, it appears that
none of my changes for Python support on Solaris are in there.
should I then assume that neither trunk or ganglia-3.1 had any python
support related patches committed from you then?
In one branch I started working on I tried setting up my own LDFLAGS for
Python, e.g. in configure.in:
LDFLAGS_PYTHON=-lpython${PY_VERSION}
or for static:
LDFLAGS_PYTHON=/opt/csw/lib/python2.3/config/libpython${PY_VERSION}.a -lm
and using LDFLAGS_PYTHON with when linking the Python module.
the following should be all that is needed IMHO (not tested and assuming the
location/name of the python binary from your previous comments) :
./configure --with-python=/opt/csw/bin/python2.3
However, I don't think this is best practice for configure.in. I can
have a go at making it work, but it would be useful to agree on the
compatibility requirements first: e.g. should compatibility with
CSWpython be the main goal, or do we want to set some other criteria?
not sure what you mean here, but AFAIK the objective was to be able to use
python2.3 or higher (just because CentOS 4 uses that)
Solaris 10 comes with python2.3 and python2.4 (Through SUNWPython) but in
theory any version of python should work if configure is pointed to it.
In Gentoo Linux 10.0 amd64, Fedora 12 or Ubuntu Karmic that came with
python 2.6 all python modules should work even if the tcpconn.py module
might warn about deprecated use of popen (which means as soon as someone
moves to Python 3 that module at least will break)
I think the core modpython should build with any python 2.x and maybe 1.x
as well, but I don't think anyone ever tested/needed that.
I am still working through some
core agent problems (e.g. see the discussion on csw-maintainers about
building a 64 bit version of everything: I've noticed that when running
a 32 bit binary on some 64 bit machines with lot's of RAM, some kstat
calls lead to a seg fault)
care to provide a link to the thread or any bug reports?, earlier releases
for 3.0 required 64bit binaries as they were reading kernel memory directly
to gather the statistics, but after those metrics were migrated to kstat
that shouldn't be an issue anymore, and I am running some 32-bit 3.0 agent
with solaris sparc with significant amount of memory as well, so there
might be a regression to track here.
I've been discussing the issue privately with Dago, it is easily
reproducible on the host called build8st in the CSW build farm. All my
latest packages are on the box already so if you request an account, you
can try it. I'll forward you the email.
OK, the problem might be Solaris8 specific then, since my Solaris 9 and 10
binaries didn't have that problem. Hopefully will be able to figure out
how to get a CSW account then, but if you could get a core dump (better
if from an unstriped binary) or some backtraces could help on debugging
this issue.
The more general discussion on building packages containing both 32 and
64 bit libraries started here:
http://lists.opencsw.org/pipermail/maintainers/2009-October/004687.html
OK, do you have any references or documentation for the kstat requirement
on 64bit kernels?, at least on my Solaris 10u7 system vmstat is 32bit and
linked against a 32bit version of libkstat (even if a 64bit version is
also available)
Carlo
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [Ganglia-general] Ganglia 3.1.4 beta ready for testing
On Thu, Oct 29, 2009 at 01:10:14PM -0700, Bernard Li wrote: On Thu, Oct 29, 2009 at 12:01 PM, Carlo Marcelo Arenas Belon care...@sajinet.com.pe wrote: this is a bug on the autoconf from CentOS 4 which is used to build the release packages, therefore you can also workaround the issue by rebootstrapping the package or making your own with a better version of the autotools. ?for simplicity I'd uploaded an unofficial release package for 3.1.4 bootstrapped on fedora rawhide in : ?http://sajino.sajinet.com.pe/ganglia/ganglia-3.1.4.tar.gz Do you have a link for the bug, and are you aware whether there are updates for CentOS 4 to fix the issue? I am not aware of a CentOS or RHEL bug report, but considering that EL4 is in maintenance mode there won't be a fix anyway (2.59 was released in 2003 and the last update to package was in 2004) I guess I could start building on CentOS 5, provided that the autoconf does not have this bug. CentOS 5 also uses autoconf 2.59 so wouldn't help with this problem, but might hopefully allow us remove all the kludges that were added to workaround the libtool 1.5.6 bugs which were preventing DragonFlyBSD support. Ideally, which platform is used to bootstrap shouldn't be relevant though and IMHO we should be instead aiming to the latest versions of the autotools (either installed by hand or provided as part of the distribution if more development focused) and for that when on Linux usually means Fedora, Gentoo or Debian IMHO. Carlo -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [Ganglia-general] Ganglia 3.1.4 beta ready for testing
Hi Carlo: On Thu, Oct 29, 2009 at 4:47 PM, Carlo Marcelo Arenas Belon care...@sajinet.com.pe wrote: Ideally, which platform is used to bootstrap shouldn't be relevant though and IMHO we should be instead aiming to the latest versions of the autotools (either installed by hand or provided as part of the distribution if more development focused) and for that when on Linux usually means Fedora, Gentoo or Debian IMHO. I have no problem with this in theory, but would new version of autotools create a tarball that is backward compatible? Cheers, Bernard -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] bootstrapping ganglia with modern autotool versions for release (was Re: Ganglia 3.1.4 beta ready for testing)
Trimming CC and changing Subject to reflect thread better On Thu, Oct 29, 2009 at 04:54:17PM -0700, Bernard Li wrote: On Thu, Oct 29, 2009 at 4:47 PM, Carlo Marcelo Arenas Belon care...@sajinet.com.pe wrote: Ideally, which platform is used to bootstrap shouldn't be relevant though and IMHO we should be instead aiming to the latest versions of the autotools (either installed by hand or provided as part of the distribution if more development focused) and for that when on Linux usually means Fedora, Gentoo or Debian IMHO. I have no problem with this in theory, but would new version of autotools create a tarball that is backward compatible? Curious about how a backward compatible tarball would be like, but if by that you meant that you can use the resulting configure script and supporting files on systems that are much older and that never had a package for autotools with the same version that were used, then the answer is yes, that is the whole point of autotools anyway, to support other systems than the one that was originally used to build the code on, without requiring to have any of the autotools themselves installed. As for testing, is there any problem you had found on the unofficial package that I posted and that was build on Fedora Rawhide x86 : http://sajino.sajinet.com.pe/ganglia/ganglia-3.1.4.tar.gz Other than being able to work on Solaris and not asking for an unnecessary C++ compiler I wouldn't expect it to be that different when used to build ganglia binaries. Carlo -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
