Skip to contentSkip to conversation

Another round of fixes for autoconf

PATCH New Roger Pau Monne 4 participants 23 messages Feb 22, 2012 – Apr 4, 2012

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Another round of fixes for autoconf

Add checks for curses library, bin86, bcc and iasl. Also fix python-dev check.

#1 lore raw

PATCH 1/1 imported patch add_ncurses_autoconf

# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1329928648 -3600
# Node ID 6e86cecd06046b53373b3cbe756d6a9981ff73d3 # Parent caf03354472676522f7407a80ad5bec3963a90a9 imported patch add_ncurses_autoconf

tools/configure +114 -0
diff -r caf033544726 -r 6e86cecd0604 tools/configure
@@ -3907,6 +3907,8 @@ case $host_os in *\ *) host_os=`echo "$h
 # PKG_CHECK_MODULES
 
 
+
+
 # Enable/disable options
 # Check whether --enable-xsm was given.
 if test "${enable_xsm+set}" = set; then :
@@ -6380,6 +6382,118 @@ if test "$libuuid" != "y"; then :
 fi
 
 
+ac_fn_c_check_header_mongrel "$LINENO" "curses.h" "ac_cv_header_curses_h" "$ac_includes_default"
+if test "x$ac_cv_header_curses_h" = x""yes; then :
+  cursesh="y"
+else
+  cursesh="n"
+fi
+
+
+ac_fn_c_check_header_mongrel "$LINENO" "ncurses.h" "ac_cv_header_ncurses_h" "$ac_includes_default"
+if test "x$ac_cv_header_ncurses_h" = x""yes; then :
+  ncursesh="y"
+else
+  ncursesh="n"
+fi
+
+
+if test "$cursesh" = "n" && test "$ncursesh" = "n"; then :
+
+    as_fn_error $? "Unable to find a suitable curses header" "$LINENO" 5
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lcurses" >&5
+$as_echo_n "checking for clear in -lcurses... " >&6; }
+if test "${ac_cv_lib_curses_clear+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lcurses  $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char clear ();
+int
+main ()
+{
+return clear ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_lib_curses_clear=yes
+else
+  ac_cv_lib_curses_clear=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_curses_clear" >&5
+$as_echo "$ac_cv_lib_curses_clear" >&6; }
+if test "x$ac_cv_lib_curses_clear" = x""yes; then :
+  curses="y"
+else
+  curses="n"
+fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lncurses" >&5
+$as_echo_n "checking for clear in -lncurses... " >&6; }
+if test "${ac_cv_lib_ncurses_clear+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lncurses  $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char clear ();
+int
+main ()
+{
+return clear ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_lib_ncurses_clear=yes
+else
+  ac_cv_lib_ncurses_clear=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ncurses_clear" >&5
+$as_echo "$ac_cv_lib_ncurses_clear" >&6; }
+if test "x$ac_cv_lib_ncurses_clear" = x""yes; then :
+  ncurses="y"
+else
+  ncurses="n"
+fi
+
+if test "$curses" = "n" && test "$ncurses" = "n"; then :
+
+    as_fn_error $? "Unable to find a suitable curses library" "$LINENO" 5
+
+fi
+
+
 
 
 
tools/configure.ac +2 -0
diff -r caf033544726 -r 6e86cecd0604 tools/configure.ac
@@ -33,6 +33,7 @@ m4_include([m4/default_lib.m4])
 m4_include([m4/set_cflags_ldflags.m4])
 m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
+m4_include([m4/curses.m4])
 
 # Enable/disable options
 AX_ARG_ENABLE_AND_EXPORT([xsm],
@@ -102,6 +103,7 @@ AS_IF([test "x$pythontools" = "xy"], [
 ])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
 AX_CHECK_UUID
+AX_CHECK_CURSES
 PKG_CHECK_MODULES(glib, glib-2.0)
 
 # Check library path
#2 lore raw

PATCH 1/1 autoconf: add check for curses library

# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1329929131 -3600
# Node ID a6af2a82f9de757b529465c3941363507264272e # Parent caf03354472676522f7407a80ad5bec3963a90a9
autoconf: add check for curses library

Check for a curses compatible library (curses or ncurses basically). One of those is needed to compile Xen tools.

tools/configure +114 -0
diff -r caf033544726 -r a6af2a82f9de tools/configure
@@ -3907,6 +3907,8 @@ case $host_os in *\ *) host_os=`echo "$h
 # PKG_CHECK_MODULES
 
 
+
+
 # Enable/disable options
 # Check whether --enable-xsm was given.
 if test "${enable_xsm+set}" = set; then :
@@ -6380,6 +6382,118 @@ if test "$libuuid" != "y"; then :
 fi
 
 
+ac_fn_c_check_header_mongrel "$LINENO" "curses.h" "ac_cv_header_curses_h" "$ac_includes_default"
+if test "x$ac_cv_header_curses_h" = x""yes; then :
+  cursesh="y"
+else
+  cursesh="n"
+fi
+
+
+ac_fn_c_check_header_mongrel "$LINENO" "ncurses.h" "ac_cv_header_ncurses_h" "$ac_includes_default"
+if test "x$ac_cv_header_ncurses_h" = x""yes; then :
+  ncursesh="y"
+else
+  ncursesh="n"
+fi
+
+
+if test "$cursesh" = "n" && test "$ncursesh" = "n"; then :
+
+    as_fn_error $? "Unable to find a suitable curses header" "$LINENO" 5
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lcurses" >&5
+$as_echo_n "checking for clear in -lcurses... " >&6; }
+if test "${ac_cv_lib_curses_clear+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lcurses  $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char clear ();
+int
+main ()
+{
+return clear ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_lib_curses_clear=yes
+else
+  ac_cv_lib_curses_clear=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_curses_clear" >&5
+$as_echo "$ac_cv_lib_curses_clear" >&6; }
+if test "x$ac_cv_lib_curses_clear" = x""yes; then :
+  curses="y"
+else
+  curses="n"
+fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for clear in -lncurses" >&5
+$as_echo_n "checking for clear in -lncurses... " >&6; }
+if test "${ac_cv_lib_ncurses_clear+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lncurses  $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char clear ();
+int
+main ()
+{
+return clear ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_lib_ncurses_clear=yes
+else
+  ac_cv_lib_ncurses_clear=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ncurses_clear" >&5
+$as_echo "$ac_cv_lib_ncurses_clear" >&6; }
+if test "x$ac_cv_lib_ncurses_clear" = x""yes; then :
+  ncurses="y"
+else
+  ncurses="n"
+fi
+
+if test "$curses" = "n" && test "$ncurses" = "n"; then :
+
+    as_fn_error $? "Unable to find a suitable curses library" "$LINENO" 5
+
+fi
+
+
 
 
 
tools/configure.ac +2 -0
diff -r caf033544726 -r a6af2a82f9de tools/configure.ac
@@ -33,6 +33,7 @@ m4_include([m4/default_lib.m4])
 m4_include([m4/set_cflags_ldflags.m4])
 m4_include([m4/uuid.m4])
 m4_include([m4/pkg.m4])
+m4_include([m4/curses.m4])
 
 # Enable/disable options
 AX_ARG_ENABLE_AND_EXPORT([xsm],
@@ -102,6 +103,7 @@ AS_IF([test "x$pythontools" = "xy"], [
 ])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
 AX_CHECK_UUID
+AX_CHECK_CURSES
 PKG_CHECK_MODULES(glib, glib-2.0)
 
 # Check library path
#3 lore raw

Re: [PATCH 1 of 3] imported patch add_ncurses_autoconf

In reply to Roger Pau Monne

2012/2/22 Roger Pau Monne <[email protected]>:

Quoted 6 lines

# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1329928648 -3600
# Node ID 6e86cecd06046b53373b3cbe756d6a9981ff73d3 # Parent  caf03354472676522f7407a80ad5bec3963a90a9 imported patch add_ncurses_autoconf

Forget about this patch, I have to resend it.

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#4 lore raw

Re: [PATCH 1 of 3] imported patch add_ncurses_autoconf

In reply to Roger Pau Monne

Roger Pau Monne writes ("[PATCH 1 of 3] imported patch add_ncurses_autoconf"):

Quoted 1 line

imported patch add_ncurses_autoconf

Did you forget to add curses.m4 ?

Ian.

#5 lore raw

Re: [PATCH 1 of 3] imported patch add_ncurses_autoconf

2012/3/12 Ian Jackson <[email protected]>:

Quoted 4 lines

Roger Pau Monne writes ("[PATCH 1 of 3] imported patch add_ncurses_autoconf"):

Quoted 1 line

imported patch add_ncurses_autoconf

Did you forget to add curses.m4 ?

Yes, forget about this patch, it is completely wrong.

Quoted 6 lines

Ian.

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#6 lore raw

PATCH 1/1 autoconf: check for as86, ld86, bcc and iasl

In reply to Roger Pau Monne

# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1329928670 -3600
# Node ID 04c74f6b97ad74ecd3226be5a4c7478859a74aec # Parent 6e86cecd06046b53373b3cbe756d6a9981ff73d3
autoconf: check for as86, ld86, bcc and iasl

Check for this tools, and set the proper paths on config/Tool.mk.

config/Tools.mk.in +4 -0
diff -r 6e86cecd0604 -r 04c74f6b97ad config/Tools.mk.in
@@ -15,6 +15,10 @@ CURL_CONFIG         := @CURL@
 XML2_CONFIG         := @XML@
 BASH                := @BASH@
 XGETTTEXT           := @XGETTEXT@
+AS86                := @AS86@
+LD86                := @LD86@
+BCC                 := @BCC@
+IASL                := @IASL@
 
 # Extra folder for libs/includes
 PREPEND_INCLUDES    := @PREPEND_INCLUDES@
tools/configure +196 -0

226 lines not on this page · raw message

tools/configure.ac +8 -0
diff -r 6e86cecd0604 -r 04c74f6b97ad tools/configure.ac
@@ -68,6 +68,10 @@ AC_ARG_VAR([CURL], [Path to curl-config 
 AC_ARG_VAR([XML], [Path to xml2-config tool])
 AC_ARG_VAR([BASH], [Path to bash shell])
 AC_ARG_VAR([XGETTEXT], [Path to xgetttext tool])
+AC_ARG_VAR([AS86], [Path to as86 tool])
+AC_ARG_VAR([LD86], [Path to ld86 tool])
+AC_ARG_VAR([BCC], [Path to bcc tool])
+AC_ARG_VAR([IASL], [Path to iasl tool])
 
 # Checks for programs.
 AC_PROG_SED
@@ -102,6 +106,10 @@ AS_IF([test "x$pythontools" = "xy"], [
     AX_CHECK_PYTHON_DEVEL()
 ])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
+AX_PATH_PROG_OR_FAIL([AS86], [as86])
+AX_PATH_PROG_OR_FAIL([LD86], [ld86])
+AX_PATH_PROG_OR_FAIL([BCC], [bcc])
+AX_PATH_PROG_OR_FAIL([IASL], [iasl])
 AX_CHECK_UUID
 AX_CHECK_CURSES
 PKG_CHECK_MODULES(glib, glib-2.0)
#7 lore raw

Re: [PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl

Quoted 11 lines · Roger Pau Monne

# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1329928670 -3600
# Node ID 04c74f6b97ad74ecd3226be5a4c7478859a74aec # Parent 6e86cecd06046b53373b3cbe756d6a9981ff73d3
autoconf: check for as86, ld86, bcc and iasl

Check for this tools, and set the proper paths on config/Tool.mk.

I've recently submitted patches to enable/disable building of rombios/vgabios in hvmloader through options in Config.mk:

CONFIG_ROMBIOS ?= y
CONFIG_SEABIOS ?= y

If rombios is disabled, then we shouldn't depend on bcc any longer.

Is it possible to introduce an option in the configure script to set the above variables and not require bcc/as86/ld86 if not building rombios support in hvmloader ?

Signature · 1 line
Julian
Acked-by on v1 1/1
#8 lore raw

Re: [PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl

In reply to Roger Pau Monne

Roger Pau Monne writes ("[PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl"):

Quoted 3 lines

autoconf: check for as86, ld86, bcc and iasl

Check for this tools, and set the proper paths on config/Tool.mk.

This looks plausible.

#9 lore raw

Re: [PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl

2012/3/12 Ian Jackson <[email protected]>:

Quoted 8 lines

Roger Pau Monne writes ("[PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl"):

Quoted 3 lines

autoconf: check for as86, ld86, bcc and iasl

Check for this tools, and set the proper paths on config/Tool.mk.

This looks plausible.

Could this be applied before the 4.2 freeze?

Thanks, Roger.

#10 lore raw

Re: [PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl

Roger Pau Monné writes ("Re: [PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl"):

Quoted 11 lines

2012/3/12 Ian Jackson <[email protected]>:

Quoted 8 lines

Roger Pau Monne writes ("[PATCH 2 of 3] autoconf: check for as86, ld86, bcc and iasl"):

Quoted 3 lines

autoconf: check for as86, ld86, bcc and iasl

Check for this tools, and set the proper paths on config/Tool.mk.

This looks plausible.

Could this be applied before the 4.2 freeze?

Yes, I have applied it now. I had acked it, but at that time it seemed that you were going to repost the series because of other things in it, and I didn't apply it on its own. But in fact it looks fine by itself.

Ian.

#11 lore raw

PATCH 1/1 autoconf: check for Python.h header and -lpython lib

In reply to Roger Pau Monne

# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1329928675 -3600
# Node ID d27037d4c8ef217effb9d063db3bb620ba3762aa # Parent 04c74f6b97ad74ecd3226be5a4c7478859a74aec
autoconf: check for Python.h header and -lpython lib

Check that the usually called python-dev package is present.

tools/configure +71 -20
diff -r 04c74f6b97ad -r d27037d4c8ef tools/configure
@@ -6270,26 +6270,77 @@ else
     { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
 fi
-    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for python devel" >&5
-$as_echo_n "checking for python devel... " >&6; }
-
-`$PYTHON -c '
-import os.path, sys
-for p in sys.path:
-    if os.path.exists(p + "/config/Makefile"):
-        sys.exit(0)
-sys.exit(1)
-' > /dev/null 2>&1`
-
-if test "$?" != "0"
-then
-    { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-    as_fn_error $? "Python devel package not found" "$LINENO" 5
-else
-    { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
-$as_echo "yes" >&6; }
-fi
+
+ac_previous_cppflags=$CPPFLAGS
+CPPFLAGS="$CFLAGS `$PYTHON-config --includes`"
+ac_previous_ldflags=$LDFLAGS
+for flag in `$PYTHON-config --ldflags`
+do
+    if test ${flag:0:2} = "-L"; then :
+
+        LDFLAGS="$LDLFAGS $flag"
+
+fi
+    if test ${flag:0:8} = "-lpython"; then :
+
+        python_lib=${flag:2}
+
+fi
+done
+ac_fn_c_check_header_mongrel "$LINENO" "Python.h" "ac_cv_header_Python_h" "$ac_includes_default"
+if test "x$ac_cv_header_Python_h" = x""yes; then :
+
+else
+  as_fn_error $? "Unable to find Python development headers" "$LINENO" 5
+fi
+
+
+as_ac_Lib=`$as_echo "ac_cv_lib_$python_lib''_main" | $as_tr_sh`
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for main in -l$python_lib" >&5
+$as_echo_n "checking for main in -l$python_lib... " >&6; }
+if eval "test \"\${$as_ac_Lib+set}\"" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-l$python_lib  $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+
+int
+main ()
+{
+return main ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  eval "$as_ac_Lib=yes"
+else
+  eval "$as_ac_Lib=no"
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+eval ac_res=\$$as_ac_Lib
+	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+if eval test \"x\$"$as_ac_Lib"\" = x"yes"; then :
+  cat >>confdefs.h <<_ACEOF
+#define `$as_echo "HAVE_LIB$python_lib" | $as_tr_cpp` 1
+_ACEOF
+
+  LIBS="-l$python_lib $LIBS"
+
+else
+  as_fn_error $? "Unable to find a suitable python development library" "$LINENO" 5
+fi
+
+CPPFLAGS=$ac_previous_cppflags
+LDLFAGS=$ac_previous_ldflags
+
 
 fi
 # Extract the first word of "xgettext", so it can be a program name with args.
tools/m4/python_devel.m4 +20 -18
diff -r 04c74f6b97ad -r d27037d4c8ef tools/m4/python_devel.m4
@@ -1,18 +1,20 @@
-AC_DEFUN([AX_CHECK_PYTHON_DEVEL],
-[AC_MSG_CHECKING([for python devel])
-
-`$PYTHON -c '
-import os.path, sys
-for p in sys.path:
-    if os.path.exists(p + "/config/Makefile"):
-        sys.exit(0)
-sys.exit(1)
-' > /dev/null 2>&1`
-
-if test "$?" != "0"
-then
-    AC_MSG_RESULT([no])
-    AC_MSG_ERROR([Python devel package not found])
-else
-    AC_MSG_RESULT([yes])
-fi])
+AC_DEFUN([AX_CHECK_PYTHON_DEVEL], [
+ac_previous_cppflags=$CPPFLAGS
+CPPFLAGS="$CFLAGS `$PYTHON-config --includes`"
+ac_previous_ldflags=$LDFLAGS
+for flag in `$PYTHON-config --ldflags`
+do
+    AS_IF([test ${flag:0:2} = "-L"], [
+        LDFLAGS="$LDLFAGS $flag"
+    ])
+    AS_IF([test ${flag:0:8} = "-lpython"], [
+        python_lib=${flag:2}
+    ])
+done
+AC_CHECK_HEADER([Python.h], [],
+    [AC_MSG_ERROR([Unable to find Python development headers])],)
+AC_CHECK_LIB($python_lib, main, [],
+    [AC_MSG_ERROR([Unable to find a suitable python development library])])
+CPPFLAGS=$ac_previous_cppflags
+LDLFAGS=$ac_previous_ldflags
+])
#12 lore raw

Re: [PATCH 3 of 3] autoconf: check for Python.h header and -lpython lib

Roger Pau Monne writes ("[PATCH 3 of 3] autoconf: check for Python.h header and -lpython lib"):

Quoted 1 line

+ AS_IF([test ${flag:0:2} = "-L"], [

This syntax, ${flag:0:2}, is not POSIX. You should use case. I think we can safely dispense with the use of AS_IF.

tools/m4/python_devel.m4 line 12

Quoted 5 lines
tools/m4/python_devel.m4 +5 -0
+        LDFLAGS="$LDLFAGS $flag"
+    ])
+    AS_IF([test ${flag:0:8} = "-lpython"], [
+        python_lib=${flag:2}
+    ])

I see that you are throwing away all other -l* options. This deserves a comment. You probably also want to barf if you find options which are not -L or -l.

Ian.

#13 lore raw

PATCH v2 1/1 autoconf: check for Python.h header and -lpython* lib

# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1329953110 -3600
# Node ID 56c370dc64c17a770dd3cb04b81f9c27dab54d4b # Parent f8c0e7ac5a9510a54a48ada6aca5636b9017cdee
autoconf: check for Python.h header and -lpython* lib

Check that the usually called python-dev package is present.

Changes since v1:

* Use "case" instead of ${flag...} = ....

* Add comment explaining why we drop -l* flags from python-config.

tools/configure +82 -20
diff -r f8c0e7ac5a95 -r 56c370dc64c1 tools/configure
@@ -6271,26 +6271,88 @@ else
     { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
 fi
-    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for python devel" >&5
-$as_echo_n "checking for python devel... " >&6; }
-
-`$PYTHON -c '
-import os.path, sys
-for p in sys.path:
-    if os.path.exists(p + "/config/Makefile"):
-        sys.exit(0)
-sys.exit(1)
-' > /dev/null 2>&1`
-
-if test "$?" != "0"
-then
-    { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-    as_fn_error $? "Python devel package not found" "$LINENO" 5
-else
-    { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
-$as_echo "yes" >&6; }
-fi
+
+ac_previous_cppflags=$CPPFLAGS
+CPPFLAGS="$CFLAGS `$PYTHON-config --includes`"
+ac_previous_ldflags=$LDFLAGS
+for flag in `$PYTHON-config --ldflags`
+do
+    case $flag in
+    -L*)
+        LDFLAGS="$LDLFAGS $flag"
+        ;;
+    -lpython*)
+        python_lib=`echo $flag | sed 's/^-l//'`
+        ;;
+    -l*)
+        # Ignore other libraries, we are only interested in testing python-dev
+        ;;
+    *)
+        { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Strange ldflag found in $PYTHON-config output: $flag" >&5
+$as_echo "$as_me: WARNING: Strange ldflag found in $PYTHON-config output: $flag" >&2;}
+        ;;
+    esac
+done
+ac_fn_c_check_header_mongrel "$LINENO" "Python.h" "ac_cv_header_Python_h" "$ac_includes_default"
+if test "x$ac_cv_header_Python_h" = x""yes; then :
+
+else
+  as_fn_error $? "Unable to find Python development headers" "$LINENO" 5
+fi
+
+
+as_ac_Lib=`$as_echo "ac_cv_lib_$python_lib''_PyArg_ParseTuple" | $as_tr_sh`
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for PyArg_ParseTuple in -l$python_lib" >&5
+$as_echo_n "checking for PyArg_ParseTuple in -l$python_lib... " >&6; }
+if eval "test \"\${$as_ac_Lib+set}\"" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-l$python_lib  $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char PyArg_ParseTuple ();
+int
+main ()
+{
+return PyArg_ParseTuple ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  eval "$as_ac_Lib=yes"
+else
+  eval "$as_ac_Lib=no"
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+eval ac_res=\$$as_ac_Lib
+	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+if eval test \"x\$"$as_ac_Lib"\" = x"yes"; then :
+  cat >>confdefs.h <<_ACEOF
+#define `$as_echo "HAVE_LIB$python_lib" | $as_tr_cpp` 1
+_ACEOF
+
+  LIBS="-l$python_lib $LIBS"
+
+else
+  as_fn_error $? "Unable to find a suitable python development library" "$LINENO" 5
+fi
+
+CPPFLAGS=$ac_previous_cppflags
+LDLFAGS=$ac_previous_ldflags
+
 
 fi
 # Extract the first word of "xgettext", so it can be a program name with args.
tools/m4/python_devel.m4 +28 -18

46 lines not on this page · raw message

#14 lore raw

Re: [PATCH v2] autoconf: check for Python.h header and -lpython* lib

Roger Pau Monne writes ("[PATCH v2] autoconf: check for Python.h header and -lpython* lib"):

Quoted 1 line

autoconf: check for Python.h header and -lpython* lib

Right, this is better.

Quoted 1 line

+ac_previous_cppflags=$CPPFLAGS

...

tools/m4/python_devel.m4 line 27

Quoted 6 lines
tools/m4/python_devel.m4 +6 -0
+AC_CHECK_HEADER([Python.h], [],
+    [AC_MSG_ERROR([Unable to find Python development headers])],)
+AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
+    [AC_MSG_ERROR([Unable to find a suitable python development library])])
+CPPFLAGS=$ac_previous_cppflags
+LDLFAGS=$ac_previous_ldflags

But AFAICT we go to all this effort to find the right python flags and then we throw them away. This is a bit odd. Shouldn't we be passing this in some PYTHON_FOOFLAGS variables for the benefit of tools/python ?

Ian.

#15 lore raw

Re: [PATCH v2] autoconf: check for Python.h header and -lpython* lib

2012/3/12 Ian Jackson <[email protected]>:

Quoted 7 lines

Roger Pau Monne writes ("[PATCH v2] autoconf: check for Python.h header and -lpython* lib"):

Quoted 1 line

autoconf: check for Python.h header and -lpython* lib

Right, this is better.

Quoted 1 line

+ac_previous_cppflags=$CPPFLAGS

...

Quoted 10 lines

tools/m4/python_devel.m4 line 27

Quoted 6 lines
tools/m4/python_devel.m4 +6 -0
+AC_CHECK_HEADER([Python.h], [],
+    [AC_MSG_ERROR([Unable to find Python development headers])],)
+AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
+    [AC_MSG_ERROR([Unable to find a suitable python development library])])
+CPPFLAGS=$ac_previous_cppflags
+LDLFAGS=$ac_previous_ldflags

But AFAICT we go to all this effort to find the right python flags and then we throw them away.  This is a bit odd.  Shouldn't we be passing this in some PYTHON_FOOFLAGS variables for the benefit of tools/python ?

This would only be needed to compile Python C modules, but since python uses it's own standart build script (tools/python/setup.py) and we already pass to the setup.py script the desired python version to use, it already fetches the necessary includes/libs using it's own mechanisms.

Quoted 1 line

Ian.

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

Acked-by
#16 lore raw

Re: [PATCH v2] autoconf: check for Python.h header and -lpython* lib

Roger Pau Monné writes ("Re: [PATCH v2] autoconf: check for Python.h header and -lpython* lib"):

Quoted 10 lines

2012/3/12 Ian Jackson <[email protected]>:

Quoted 3 lines

But AFAICT we go to all this effort to find the right python flags and then we throw them away.  This is a bit odd.  Shouldn't we be passing this in some PYTHON_FOOFLAGS variables for the benefit of tools/python ?

This would only be needed to compile Python C modules, but since python uses it's own standart build script (tools/python/setup.py) and we already pass to the setup.py script the desired python version to use, it already fetches the necessary includes/libs using it's own mechanisms.

Ah, right. Well, good then, thanks.

#17 lore raw

Re: [PATCH v2] autoconf: check for Python.h header and -lpython* lib

In reply to Roger Pau Monné
Quoted 21 lines
Quoted 1 line
Quoted 1 line · Roger Pau Monné

2012/3/12 Ian Jackson <[email protected]>:

Quoted 1 line

Roger Pau Monne writes ("[PATCH v2] autoconf: check for Python.h header and

-lpython* lib"):

Quoted 6 lines
Quoted 1 line

autoconf: check for Python.h header and -lpython* lib

Right, this is better.

Quoted 1 line

+ac_previous_cppflags=$CPPFLAGS

...

Quoted 10 lines

tools/m4/python_devel.m4 line 27

Quoted 6 lines
tools/m4/python_devel.m4 +6 -0
+AC_CHECK_HEADER([Python.h], [],
+    [AC_MSG_ERROR([Unable to find Python development headers])],)
+AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
+    [AC_MSG_ERROR([Unable to find a suitable python development library])])
+CPPFLAGS=$ac_previous_cppflags
+LDLFAGS=$ac_previous_ldflags

But AFAICT we go to all this effort to find the right python flags and then we throw them away. This is a bit odd. Shouldn't we be passing this in some PYTHON_FOOFLAGS variables for the benefit of tools/python ?

Quoted 5 lines

This would only be needed to compile Python C modules, but since python uses it's own standart build script (tools/python/setup.py) and we already pass to the setup.py script the desired python version to use, it already fetches the necessary includes/libs using it's own mechanisms.

I'm sorry to say that, but this change is pretty incompatible: Not only does Python not provide any python-config prior to 2.5.x, but additionally was Ian's point above very valid: Stripping all the other -l options causes a configure failure for me:

configure:6176: checking for PyArg_ParseTuple in -lpython2.4
configure:6201: gcc -o conftest -g -O2 -g -O2 -I/usr/include/python2.4 -I/usr/include/python2.4
-L/usr/lib/python2.4/config conftest.c -lpython2.4 >&5
/usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function `posix_tmpnam':
(.text+0x81e): warning: the use of tmpnam_r' is dangerous, better use mkstemp' /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function `posix_tempnam':
(.text+0x90c): warning: the use of tempnam' is dangerous, better use mkstemp' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function `complex_abs':
(.text+0x54d): undefined reference to hypot' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2418): undefined reference to hypot' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x242a): undefined reference to pow' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x243f): undefined reference to atan2' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2470): undefined reference to cos' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2483): undefined reference to sin' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x24f6): undefined reference to exp' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2507): undefined reference to log' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_rem':
(.text+0x17c8): undefined reference to fmod' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_divmod':
(.text+0x25a8): undefined reference to fmod' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_pow':
(.text+0x296f): undefined reference to pow' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_pow':
(.text+0x2a03): undefined reference to fmod' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x12e): undefined reference to dlsym' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x195): undefined reference to dlopen' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x1c3): undefined reference to dlsym' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x232): undefined reference to dlerror' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_release_lock':
(.text+0x49): undefined reference to sem_post' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_acquire_lock':
(.text+0xc7): undefined reference to sem_wait' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_acquire_lock':
(.text+0xe2): undefined reference to sem_trywait' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_free_lock':
(.text+0x1f2): undefined reference to sem_destroy' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_allocate_lock':
(.text+0x267): undefined reference to sem_init' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_start_new_thread':
(.text+0x568): undefined reference to pthread_create' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_start_new_thread':
(.text+0x586): undefined reference to pthread_detach' /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function posix_forkpty':
(.text+0x3189): undefined reference to forkpty' /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function posix_openpty':
(.text+0x3218): undefined reference to `openpty'
collect2: ld returned 1 exit status

As you can see, all unresolved symbols revolve around symbols from those other libraries - the symbol looked for (PyArg_ParseTuple) is not among them.

As this is the second time (out of two tries) that the newly added configure logic causes problems for me (and hence eats time intended to be spent elsewhere), I really have to question to quality of all of this. Am I to expect that going forward I will have to plan several hours for taking a fresh snapshot, rather than just making my (usually short) patch queue apply and build?

Jan

Quoted 6 lines
Quoted 1 line

Ian.

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#18 lore raw

Re: [PATCH v2] autoconf: check for Python.h header and -lpython* lib

Quoted 122 lines
Quoted 22 lines
Quoted 2 lines · Jan Beulich
Quoted 1 line · Roger Pau Monné

2012/3/12 Ian Jackson <[email protected]>:

Quoted 1 line

Roger Pau Monne writes ("[PATCH v2] autoconf: check for Python.h header and

-lpython* lib"):

Quoted 6 lines
Quoted 1 line

autoconf: check for Python.h header and -lpython* lib

Right, this is better.

Quoted 1 line

+ac_previous_cppflags=$CPPFLAGS

...

Quoted 10 lines

Review

Quoted 6 lines
(quoted diff) +6 -0
+AC_CHECK_HEADER([Python.h], [],
+    [AC_MSG_ERROR([Unable to find Python development headers])],)
+AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
+    [AC_MSG_ERROR([Unable to find a suitable python development library])])
+CPPFLAGS=$ac_previous_cppflags
+LDLFAGS=$ac_previous_ldflags

But AFAICT we go to all this effort to find the right python flags and then we throw them away. This is a bit odd. Shouldn't we be passing this in some PYTHON_FOOFLAGS variables for the benefit of tools/python ?

Quoted 5 lines

This would only be needed to compile Python C modules, but since python uses it's own standart build script (tools/python/setup.py) and we already pass to the setup.py script the desired python version to use, it already fetches the necessary includes/libs using it's own mechanisms.

I'm sorry to say that, but this change is pretty incompatible: Not only does Python not provide any python-config prior to 2.5.x, but additionally was Ian's point above very valid: Stripping all the other -l options causes a configure failure for me:

configure:6176: checking for PyArg_ParseTuple in -lpython2.4
configure:6201: gcc -o conftest -g -O2 -g -O2 -I/usr/include/python2.4

(quoted diff) +0 -2
-I/usr/include/python2.4 
-L/usr/lib/python2.4/config conftest.c -lpython2.4   >&5

/usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function `posix_tmpnam':
(.text+0x81e): warning: the use of tmpnam_r' is dangerous, better use mkstemp' /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function `posix_tempnam':
(.text+0x90c): warning: the use of tempnam' is dangerous, better use mkstemp' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function `complex_abs':
(.text+0x54d): undefined reference to hypot' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2418): undefined reference to hypot' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x242a): undefined reference to pow' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x243f): undefined reference to atan2' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2470): undefined reference to cos' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2483): undefined reference to sin' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x24f6): undefined reference to exp' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2507): undefined reference to log' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_rem':
(.text+0x17c8): undefined reference to fmod' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_divmod':
(.text+0x25a8): undefined reference to fmod' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_pow':
(.text+0x296f): undefined reference to pow' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_pow':
(.text+0x2a03): undefined reference to fmod' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x12e): undefined reference to dlsym' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x195): undefined reference to dlopen' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x1c3): undefined reference to dlsym' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x232): undefined reference to dlerror' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_release_lock':
(.text+0x49): undefined reference to sem_post' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_acquire_lock':
(.text+0xc7): undefined reference to sem_wait' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_acquire_lock':
(.text+0xe2): undefined reference to sem_trywait' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_free_lock':
(.text+0x1f2): undefined reference to sem_destroy' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_allocate_lock':
(.text+0x267): undefined reference to sem_init' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_start_new_thread':
(.text+0x568): undefined reference to pthread_create' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_start_new_thread':
(.text+0x586): undefined reference to pthread_detach' /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function posix_forkpty':
(.text+0x3189): undefined reference to forkpty' /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function posix_openpty':
(.text+0x3218): undefined reference to `openpty'
collect2: ld returned 1 exit status

Quoted 3 lines

As you can see, all unresolved symbols revolve around symbols from those other libraries - the symbol looked for (PyArg_ParseTuple) is not among them.

A sketched out partial fix for this might be

tools/m4/python_devel.m4 +5 -3
@@ -2,17 +2,18 @@ AC_DEFUN([AX_CHECK_PYTHON_DEVEL], [
 ac_previous_cppflags=$CPPFLAGS
 CPPFLAGS="$CFLAGS `$PYTHON-config --includes`"
 ac_previous_ldflags=$LDFLAGS
+python_other_libs=
 for flag in `$PYTHON-config --ldflags`
 do
     case $flag in
     -L*)
-        LDFLAGS="$LDLFAGS $flag"
+        LDFLAGS="$LDFLAGS $flag"
         ;;
     -lpython*)
         python_lib=`echo $flag | sed 's/^-l//'`
         ;;
     -l*)
-        # Ignore other libraries, we are only interested in testing python-dev
+        python_other_libs="$python_other_libs $flag"
         ;;
     *)
         AC_MSG_WARN([Strange ldflag found in $PYTHON-config output: $flag])
@@ -22,7 +23,8 @@ done
 AC_CHECK_HEADER([Python.h], [],
     [AC_MSG_ERROR([Unable to find Python development headers])],)
 AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
-    [AC_MSG_ERROR([Unable to find a suitable python development library])])
+    [AC_MSG_ERROR([Unable to find a suitable python development library])],
+    [$python_other_libs])
 CPPFLAGS=$ac_previous_cppflags
 LDLFAGS=$ac_previous_ldflags
 ])

I didn't really re-generate tools/configure though (not sure what autoconf version would be required, and surely this wouldn't match the ones I have around), so can't claim this is syntactically correct. For my purposes I instead patched tools/configure manually.

Partial because it doesn't address the lack of python-config on pre-2.5 Python (we require >= 2.3).

I also wonder whether the -lpython* case shouldn't be cumulative in case there's more than one matching option.

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#19 lore raw

Re: [PATCH v2] autoconf: check for Python.h header and -lpython* lib

2012/3/20 Jan Beulich <[email protected]>:

Quoted 122 lines
Quoted 122 lines
Quoted 22 lines
Quoted 2 lines · Jan Beulich
Quoted 1 line · Roger Pau Monné

2012/3/12 Ian Jackson <[email protected]>:

Quoted 1 line

Roger Pau Monne writes ("[PATCH v2] autoconf: check for Python.h header and

-lpython* lib"):

Quoted 6 lines
Quoted 1 line

autoconf: check for Python.h header and -lpython* lib

Right, this is better.

Quoted 1 line

+ac_previous_cppflags=$CPPFLAGS

...

Quoted 10 lines

Review

Quoted 6 lines
(quoted diff) +6 -0
+AC_CHECK_HEADER([Python.h], [],
+    [AC_MSG_ERROR([Unable to find Python development headers])],)
+AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
+    [AC_MSG_ERROR([Unable to find a suitable python development library])])
+CPPFLAGS=$ac_previous_cppflags
+LDLFAGS=$ac_previous_ldflags

But AFAICT we go to all this effort to find the right python flags and then we throw them away.  This is a bit odd.  Shouldn't we be passing this in some PYTHON_FOOFLAGS variables for the benefit of tools/python ?

Quoted 5 lines

This would only be needed to compile Python C modules, but since python uses it's own standart build script (tools/python/setup.py) and we already pass to the setup.py script the desired python version to use, it already fetches the necessary includes/libs using it's own mechanisms.

I'm sorry to say that, but this change is pretty incompatible: Not only does Python not provide any python-config prior to 2.5.x, but additionally was Ian's point above very valid: Stripping all the other -l options causes a configure failure for me:

configure:6176: checking for PyArg_ParseTuple in -lpython2.4 configure:6201: gcc -o conftest  -g -O2   -g -O2  -I/usr/include/python2.4

(quoted diff) +0 -2
-I/usr/include/python2.4
-L/usr/lib/python2.4/config conftest.c -lpython2.4   >&5

/usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function `posix_tmpnam':
(.text+0x81e): warning: the use of tmpnam_r' is dangerous, better use mkstemp' /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function `posix_tempnam':
(.text+0x90c): warning: the use of tempnam' is dangerous, better use mkstemp' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function `complex_abs':
(.text+0x54d): undefined reference to hypot' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2418): undefined reference to hypot' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x242a): undefined reference to pow' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x243f): undefined reference to atan2' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2470): undefined reference to cos' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2483): undefined reference to sin' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x24f6): undefined reference to exp' /usr/lib/python2.4/config/libpython2.4.a(complexobject.o): In function _Py_c_pow':
(.text+0x2507): undefined reference to log' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_rem':
(.text+0x17c8): undefined reference to fmod' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_divmod':
(.text+0x25a8): undefined reference to fmod' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_pow':
(.text+0x296f): undefined reference to pow' /usr/lib/python2.4/config/libpython2.4.a(floatobject.o): In function float_pow':
(.text+0x2a03): undefined reference to fmod' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x12e): undefined reference to dlsym' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x195): undefined reference to dlopen' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x1c3): undefined reference to dlsym' /usr/lib/python2.4/config/libpython2.4.a(dynload_shlib.o): In function _PyImport_GetDynLoadFunc':
(.text+0x232): undefined reference to dlerror' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_release_lock':
(.text+0x49): undefined reference to sem_post' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_acquire_lock':
(.text+0xc7): undefined reference to sem_wait' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_acquire_lock':
(.text+0xe2): undefined reference to sem_trywait' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_free_lock':
(.text+0x1f2): undefined reference to sem_destroy' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_allocate_lock':
(.text+0x267): undefined reference to sem_init' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_start_new_thread':
(.text+0x568): undefined reference to pthread_create' /usr/lib/python2.4/config/libpython2.4.a(thread.o): In function PyThread_start_new_thread':
(.text+0x586): undefined reference to pthread_detach' /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function posix_forkpty':
(.text+0x3189): undefined reference to forkpty' /usr/lib/python2.4/config/libpython2.4.a(posixmodule.o): In function posix_openpty':
(.text+0x3218): undefined reference to `openpty'
collect2: ld returned 1 exit status

Quoted 5 lines
Quoted 3 lines

As you can see, all unresolved symbols revolve around symbols from those other libraries - the symbol looked for (PyArg_ParseTuple) is not among them.

A sketched out partial fix for this might be

I've already posted something arround this lines a few days ago:

http://lists.xen.org/archives/html/xen-devel/2012-03/msg01350.html

What I didn't know was that python-config was only available starting from 2.5, which is a real pain in the ass, I will probably have to drop the python-config stuff and move to distutils to perform this checks. Sorry for the trouble this is causing you (Jan), it's impossible for me to test on all systems/python versions that are *supported*, and I tend to run this on pretty new systems.

Quoted 40 lines
tools/m4/python_devel.m4 +0 -0
@@ -2,17 +2,18 @@ AC_DEFUN([AX_CHECK_PYTHON_DEVEL], [

 ac_previous_cppflags=$CPPFLAGS
 CPPFLAGS="$CFLAGS $PYTHON-config --includes" ac_previous_ldflags=$LDFLAGS
+python_other_libs=
 for flag in $PYTHON-config --ldflags
 do
    case $flag in
    -L*)
-        LDFLAGS="$LDLFAGS $flag"
+        LDFLAGS="$LDFLAGS $flag"
        ;;
    -lpython*)
        python_lib=echo $flag | sed 's/^-l//'
        ;;
    -l*)
-        # Ignore other libraries, we are only interested in testing python-dev
+        python_other_libs="$python_other_libs $flag"
        ;;
    *)
        AC_MSG_WARN([Strange ldflag found in $PYTHON-config output: $flag])

tools/m4/python_devel.m4 +2 -1
@@ -22,7 +23,8 @@ done
  AC_CHECK_HEADER([Python.h], [],
     [AC_MSG_ERROR([Unable to find Python development headers])],)
  AC_CHECK_LIB($python_lib, PyArg_ParseTuple, [],
-    [AC_MSG_ERROR([Unable to find a suitable python development library])])
+    [AC_MSG_ERROR([Unable to find a suitable python development library])],
+    [$python_other_libs])

 CPPFLAGS=$ac_previous_cppflags
 LDLFAGS=$ac_previous_ldflags
 ])

I didn't really re-generate tools/configure though (not sure what autoconf version would be required, and surely this wouldn't match the ones I have around), so can't claim this is syntactically correct. For my purposes I instead patched tools/configure manually.

Quoted 5 lines

Partial because it doesn't address the lack of python-config on pre-2.5 Python (we require >= 2.3).

I also wonder whether the -lpython* case shouldn't be cumulative in case there's more than one matching option.

I don't think python-config will output more than one -lpython*, I have systems with more than one python version, and I have python(version)-config for each one of them, but plain python-config just outputs a single version to link to.

Quoted 1 line

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#20 lore raw

Re: [PATCH v2] autoconf: check for Python.h header and -lpython* lib

Quoted 9 lines
Quoted 1 line
Quoted 1 line · Roger Pau Monné

2012/3/20 Jan Beulich <[email protected]>:

Quoted 2 lines

I also wonder whether the -lpython* case shouldn't be cumulative in case there's more than one matching option.

I don't think python-config will output more than one -lpython*, I have systems with more than one python version, and I have python(version)-config for each one of them, but plain python-config just outputs a single version to link to.

That is what you observe currently. But my point is that the purpose of python-config is to abstract away e.g. a future library split.

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

#21 lore raw

Re: [PATCH v2] autoconf: check for Python.h header and -lpython* lib

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] autoconf: check for Python.h header and -lpython* lib"):

Quoted 2 lines

That is what you observe currently. But my point is that the purpose of python-config is to abstract away e.g. a future library split.

There is not going to be any future library split because Python 2.7 is going to be the last 2.x.

If and when we support Python 3 we'll have an entirely separate pile of machinery for it.

Ian.