Trimming CC and changing Subject to better focus this thread
On Thu, Oct 29, 2009 at 10:09:32PM +0000, 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
