Carlo Marcelo Arenas Belon wrote:
> On Thu, Oct 29, 2009 at 08:42:05PM +0000, Daniel Pocock wrote:
>
>> Carlo Marcelo Arenas Belon wrote:
>>
>>> On Thu, Oct 29, 2009 at 04:44:59PM +0000, 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
