On Fri, 24 Feb 2006, Davis, Jacob wrote:
> Many thanks for your insightful suggestions. Setting the following
> environment variables has allowed me to get beyond the mgmt/python
> issue.
> Note that I also removed the blaswave version of python.
OK. (I took your email as a trigger for myself to start looking at the
blastwave software! It has been useful.)
Regarding the pythom problem you encountered: Blastwave/python is probably
innocent. Rather the problem seems to be in our (heartbeat) insufficently
discovering (and make too many assumptions about) the environment of any
particular installation's python.
> PATH=/usr/bin:/sbin:/usr/sbin:/usr/sfw/bin:/opt/sfw/bin:/usr/sfw/sbin:/o
> pt/sfw/sbin:/usr/ccs/bin:/opt/csw/bin:/opt/csw/sbin
> CPPFLAGS="-I/usr/sfw/include -I/usr/sfw/include/python2.3
> -I/opt/sfw/include -I/opt/csw/include"
> LDFLAGS="-L/usr/sfw/lib -L/usr/sfw/lib/python2.3 -L/usr/ccs/lib -L
> /opt/sfw/lib -L/opt/csw/lib"
What is "sfw"? Is it the sunfreeware set of packages (analogous/parallel
to blaswave/csw)?
Anyway: Attached are three small items (in effect, a patch) whose
intention is to handle the python issue better. They are:
1. new top-level file "acinclude.m4": define a macro to find the python
headers files and to set a shell variable;
2. patch to "configure.in": use that shell variable to set "Makefile.am";
3. patch to "lib/mgmt/Makefile.am": use this information.
This ought to be cleaner and more robust than the earlier method.
If you are able to try it, I would urge a clean build, starting afresh
from the "ConfigureMe bootstrap ..." stage.
> Now I'm experiencing more hang-ups. I'd like to ensure that I am
> starting with a sane environment before continuing. I hate to impose
> further but, as you mentioned having built heartbeat on your own S10
> box, [...]
Slight correction. I routinely build on S8 and S9. But due to a little
local difficulty with a known GNU/ld bug exposed by S10 (they have a fix
but haven't released a version including it), I haven't actually built on
S10. But I think that may be irrelevant for this conversation.
> [...] I was hoping you could provide some information on how you went
> about configuring your environment. Specifically what dependency
> packages and versions you have installed and were to obtain them
> (sun.com freeware, blastwave, etc), any patches that have been applied,
> how you hid the python installation from configure. Would an older
> version of Heartbeat be appropriate?
Heartbeat versions: My strong recommendation is the latest versions
(whether in the 1.2.x or 2.0.x series). Heartbeat is primarily written
around Linux. We have a good portability framework for other UN*X but (as
you have discovered) some of the detail on that framework is weak or
lacking. Both branches (1.2.x and 2.0.x) have benefically evolved over
time in this regard.
My own environment of bolt-on packages (e.g. "glib") has tended to be
"grab the tar.gz and build".
Your email has highlighted the possible benefits of confirming and
ensuring that our portability framework can work with sunfreeware,
blastwave, etc.
Python: In my own case, I had never tripped over the "lib/mgmt" problem
because we didn't have TLS, and so configure ensured that we never went
down into "lib/mgmt" (which is where the python includes problem gets
exposed).
> Or, if any of this has been documented somewhere already, a pointer to
> that info.
There are very few of us using non-Linux as a heartbeat platform. So the
fact that previously unknown problems emerge is not surprising. (Nor, of
course, are they documented!)
So feedback such as your is very useful.
> Thanks again and sorry to bother you. I can repost elsewhere if you
> think it is appropriate.
It would be best to keep this on the "linux-ha-dev" list. So I'm
returning this conversation to there.
I recommend you to join it (if you have not already done so). It has low
traffic levels, and high quality content. It also gives you a feel for
how the project is developing, and the thoroughness with which matters are
treated.
> If you're curious about the new errors they are as follows.....
>
> ----------------
> Making all in stonith
> gmake[2]: Entering directory
> [...]
> ld: fatal: file /opt/sfw/lib: unknown file type
> ld: fatal: File processing errors. No output written to .libs/stonith
> collect2: ld returned 1 exit status
> gmake[2]: *** [stonith] Error 1
> gmake[2]: Leaving directory `/root/download/heartbeat-2.0.3/lib/stonith'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/root/download/heartbeat-2.0.3/lib'
> gmake: *** [all-recursive] Error 1
Not seen that one!
The known S10+GNU/ld problem manifests as a set of four messages:
... undefined reference to [EMAIL PROTECTED]'
... undefined reference to [EMAIL PROTECTED]'
... undefined reference to [EMAIL PROTECTED]'
... undefined reference to [EMAIL PROTECTED]'
In theory, the general idea of "configure" and "make" allows you to patch
things and rebuild, and the rebuild only does what is necessary.
In practice, however, that may not be prefect. So it can often be a good
idea, especially after major changes of environment (e.g. changing from,
say,one python installation to another.
So it may be worth a clean sweep: unpack the source to a new location;
apply (if you wish) my patches; then "ConfigureMe bootstrap ...".
Hope that helps.
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :dnl
dnl local autoconf/automake macros needed for heartbeat
dnl Started by David Lee <[EMAIL PROTECTED]> February 2006
dnl
dnl License: GNU General Public License (GPL)
## Find the install dirs for the python installation.
## By James Henstridge
dnl a macro to check for ability to create python extensions
dnl AM_CHECK_PYTHON_HEADERS([ACTION-IF-POSSIBLE], [ACTION-IF-NOT-POSSIBLE])
dnl function also defines PYTHON_INCLUDES
AC_DEFUN([AM_CHECK_PYTHON_HEADERS],
[AC_REQUIRE([AM_PATH_PYTHON])
AC_MSG_CHECKING(for headers required to compile python extensions)
dnl deduce PYTHON_INCLUDES
py_prefix=`$PYTHON -c "import sys; print sys.prefix"`
py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"`
PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
if test "$py_prefix" != "$py_exec_prefix"; then
PYTHON_INCLUDES="$PYTHON_INCLUDES
-I${py_exec_prefix}/include/python${PYTHON_VERSION}"
fi
AC_SUBST(PYTHON_INCLUDES)
dnl check if the headers exist:
save_CPPFLAGS="$CPPFLAGS"
CPPFLAGS="$CPPFLAGS $PYTHON_INCLUDES"
AC_TRY_CPP([#include <Python.h>],dnl
[AC_MSG_RESULT(found)
$1],dnl
[AC_MSG_RESULT(not found)
$2])
CPPFLAGS="$save_CPPFLAGS"
])
--- configure.in.orig Thu Feb 23 20:33:44 2006
+++ configure.in Fri Feb 24 16:07:54 2006
@@ -2254,12 +2254,13 @@
else
MISSING_FN="FatalMissingThing"
fi
- PYTHON_HEADER_DIR="python${PYTHON_VERSION}"
- AC_CHECK_HEADER($PYTHON_HEADER_DIR/Python.h,
- [python_headers_found="yes"],[python_headers_found="no"])
- if test "x${python_headers_found}" = "xno"; then
- $MISSING_FN "$PYTHON_HEADER_DIR/Python.h" \
- "The GUI managment module needs the python-devel package"
+
+ AM_CHECK_PYTHON_HEADERS(,PYTHON_INCLUDES='')
+ AC_SUBST(PYTHON_INCLUDES)
+
+ if test "x${PYTHON_INCLUDES}" = "x"; then
+ $MISSING_FN "Python.h" \
+ "The GUI managment module needs Python.h (Linux: python-devel
package)"
enable_mgmt="no"
MGMT_ENABLED=0
fi
--- lib/mgmt/Makefile.am.orig Thu Jan 26 15:04:51 2006
+++ lib/mgmt/Makefile.am Fri Feb 24 13:18:49 2006
@@ -48,7 +48,7 @@
halib_LTLIBRARIES = _pymgmt.la
_pymgmt_la_SOURCES = pymgmt_wrap.c mgmt_client_lib.c mgmt_tls_lib.c
mgmt_common_lib.c
-_pymgmt_la_CFLAGS = -I$(includedir)/@PYTHON_HEADER_DIR@
-I$(top_builddir)/include -w
+_pymgmt_la_CFLAGS = @PYTHON_INCLUDES@ -I$(top_builddir)/include -w
_pymgmt_la_LDFLAGS = -module `libgnutls-config --libs`
halib_SCRIPTS = pymgmt.py
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
