search for: python_cflags

Building against multiple versions of Python is a lot of fun as it is. Add autoconf/automake/libtool (and possible distribution-specific stuff) to the mix and things get really interesting: On Debian and Ubuntu, building against python 3.3 requires an extra include path as documented in <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692387>. As discussed in

...int (distutils.sysconfig.get_python_inc ());"` - PYTHON_INCLUDEDIR=$python_path - fi - AC_MSG_RESULT([$PYTHON_INCLUDEDIR]) + # Debian: python-2.7.pc, python-3.2.pc + PKG_CHECK_MODULES([PYTHON], [python-"$PYTHON_VERSION"],[ + AC_SUBST([PYTHON_CFLAGS]) + AC_SUBST([PYTHON_LIBS]) + AC_SUBST([PYTHON_VERSION]) + AC_DEFINE([HAVE_PYTHON],[1],[Python library found at compile time]) + ],[ + PKG_CHECK_MODULES([PYTHON], [python],[ + AC_SUBST([PYTHON_CFLAGS]) + AC_SUBST([PYTH...

...` PYTHON_VERSION="$PYTHON_VERSION_MAJOR.$PYTHON_VERSION_MINOR" AC_MSG_RESULT([$PYTHON_VERSION]) + # Debian: python-2.7.pc, python-3.2.pc PKG_CHECK_MODULES([PYTHON], [python-"$PYTHON_VERSION"],[ + have_python_module=1 AC_SUBST([PYTHON_CFLAGS]) AC_SUBST([PYTHON_LIBS]) AC_SUBST([PYTHON_VERSION]) AC_DEFINE([HAVE_PYTHON],[1],[Python library found at compile time]) ],[ PKG_CHECK_MODULES([PYTHON], [python],[ + have_python_module=1 AC_SUBST([PYTHON_CF...

...ython_inc ());"` > - PYTHON_INCLUDEDIR=$python_path > - fi > - AC_MSG_RESULT([$PYTHON_INCLUDEDIR]) > + # Debian: python-2.7.pc, python-3.2.pc > + PKG_CHECK_MODULES([PYTHON], [python-"$PYTHON_VERSION"],[ > + AC_SUBST([PYTHON_CFLAGS]) > + AC_SUBST([PYTHON_LIBS]) > + AC_SUBST([PYTHON_VERSION]) > + AC_DEFINE([HAVE_PYTHON],[1],[Python library found at compile time]) > + ],[ > + PKG_CHECK_MODULES([PYTHON], [python],[ > + AC_SUBST([PYTHON_CFLAGS]) &...

...; - PYTHON_INCLUDEDIR=$python_path > > - fi > > - AC_MSG_RESULT([$PYTHON_INCLUDEDIR]) > > + # Debian: python-2.7.pc, python-3.2.pc > > + PKG_CHECK_MODULES([PYTHON], [python-"$PYTHON_VERSION"],[ > > + AC_SUBST([PYTHON_CFLAGS]) > > + AC_SUBST([PYTHON_LIBS]) > > + AC_SUBST([PYTHON_VERSION]) > > + AC_DEFINE([HAVE_PYTHON],[1],[Python library found at compile time]) > > + ],[ > > + PKG_CHECK_MODULES([PYTHON], [python],[ > > +...

On Mon, Jun 17, 2013 at 10:08:46AM +0200, Olaf Hering wrote: > On Mon, Jun 17, Richard W.M. Jones wrote: > > > On Sun, Jun 16, 2013 at 02:55:29PM +0200, Olaf Hering wrote: > > > For me current 1.20 branch fails to build python in SLE11. > > > > Does SuSE's python have a pkg-config file? > > SLE11 does not have it, but openSUSE 11.4+ has it. > I

...[Found PyUnicode_AsUTF8 in libpython.])], - [],[$PYTHON_BLDLIBRARY]) - - LIBS="$old_LIBS" - ]) AM_CONDITIONAL([HAVE_PYTHON],[test "x$enable_python" != "xno" && test "x$PYTHON" != "xno"]) AC_SUBST([PYTHON_CFLAGS]) diff --git a/plugins/python/python.c b/plugins/python/python.c index 20232f4..2e1a53f 100644 --- a/plugins/python/python.c +++ b/plugins/python/python.c @@ -117,17 +117,9 @@ static char * python_to_string (PyObject *str) { if (str) { -#ifdef HAVE_PYUNICODE_ASUTF8 if (PyUnicode_Check (st...

...o passdb/pdb_get_set.po passdb/passdb.po passdb/pdb_interface.po passdb/machine_sid.po passdb/util_sam_sid.po passdb/pdb_compat.po passdb/privileges.po passdb/pdb_ldap.po passdb/pdb_smbpasswd.po passdb/pdb_tdb.po passdb/pdb_guest.po groupdb/mapping.po passdb/secrets.po libads/kerberos.po" \ PYTHON_CFLAGS="-g -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -g -O2 -Iinclude -I/root/samba/samba-3.0.0beta2/source/include -I/root/samba/samba-3.0.0beta2/source/ubiqx -I/root/samba/samba-3.0.0beta2/source/smbwrapper -I. -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -I/ro...

This commit starts to split our massive, monolithic configure.ac file into smaller files, using the m4_include mechanism to combine them. I don't know if we should really do this, so I'm open to comments about it. However: - Our configure.ac script is 1800+ lines long, and that's pretty long. - configure.ac lacks structure; splitting it up might improve that. - From what I read,

This patch proposes to drop support for Python 2 in nbdkit. Rather than abruptly drop it everywhere, my proposal is that we point people to nbdkit 1.14 (the current stable version) if they want to continue with Python 2 plugins, while gently reminding them of the upcoming Python 2.7 end of life announcement. Libnbd never supported Python 2. Libguestfs in theory supports Python 2 but I dropped

...fset, size) + class NBD (object): '''NBD handle''' diff --git a/python/Makefile.am b/python/Makefile.am index 48aabea..c621eb7 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -50,7 +50,8 @@ libnbdmod_la_SOURCES = \ utils.c libnbdmod_la_CPPFLAGS = \ $(PYTHON_CFLAGS) \ - -I$(top_srcdir)/include + -I$(top_srcdir)/include \ + -I$(top_srcdir)/common/include libnbdmod_la_CFLAGS = \ $(WARNINGS_CFLAGS) libnbdmod_la_LIBADD = \ diff --git a/python/handle.c b/python/handle.c index ef81ab8..da0c417 100644 --- a/python/handle.c +++ b/python/handle.c @@ -35,6 +35,8 @@...

...a_LDFLAGS = \ -module -avoid-version -shared $(NO_UNDEFINED_ON_WINDOWS) \ diff --git a/plugins/python/Makefile.am b/plugins/python/Makefile.am index b34d0394..aacc6f22 100644 --- a/plugins/python/Makefile.am +++ b/plugins/python/Makefile.am @@ -58,8 +58,9 @@ nbdkit_python_plugin_la_CFLAGS = \ $(PYTHON_CFLAGS) \ $(NULL) nbdkit_python_plugin_la_LIBADD = \ - $(PYTHON_LIBS) \ $(top_builddir)/common/utils/libutils.la \ + $(LINK_LIBNBDKIT_ON_WINDOWS) \ + $(PYTHON_LIBS) \ $(NULL) nbdkit_python_plugin_la_LDFLAGS = \ -module -avoid-version -shared $(NO_UNDEFINED_ON_WINDOWS) \ diff --git a/plugins/rand...

...-src/utils.c src/version.c src/wait.c src/whole-file.c diff --git a/python/Makefile.am b/python/Makefile.am index 0a03f73..ec99570 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -67,13 +67,14 @@ libguestfsmod_la_SOURCES = \ libguestfsmod_la_CPPFLAGS = \ -DGUESTFS_PRIVATE=1 \ $(PYTHON_CFLAGS) \ + -I$(top_srcdir)/common/utils -I$(top_builddir)/common/utils \ -I$(top_srcdir)/src -I$(top_builddir)/src libguestfsmod_la_CFLAGS = \ $(WARN_CFLAGS) $(WERROR_CFLAGS) libguestfsmod_la_LIBADD = \ - $(top_builddir)/src/libutils_la-utils.lo \ + $(top_builddir)/common/utils/libutils_la-util...

Two (not related to each other) refactorings: Patches 1-12 split configure.ac into smaller files using the m4_include mechanism. Patches 13-15 split out parts of guestfs.pod (ie. guestfs(3)) into three new manual pages: guestfs-hacking(3) - how to extend and contribute to libguestfs guestfs-internals(3) - architecture and internals guestfs-security(3) - security and CVEs Patch 16 is a

...EXTRA_CFLAGS="-DGUESTFS_PRIVATE=1" \ all diff --git a/python/Makefile.am b/python/Makefile.am index ae90aa01d..fd0825648 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -67,6 +67,7 @@ libguestfsmod_la_SOURCES = \ libguestfsmod_la_CPPFLAGS = \ -DGUESTFS_PRIVATE=1 \ $(PYTHON_CFLAGS) \ + -I$(top_srcdir)/common/cleanups -I$(top_builddir)/common/cleanups \ -I$(top_srcdir)/common/utils -I$(top_builddir)/common/utils \ -I$(top_srcdir)/lib -I$(top_builddir)/lib @@ -75,6 +76,7 @@ libguestfsmod_la_CFLAGS = \ libguestfsmod_la_LIBADD = \ $(top_builddir)/common/utils/libutils...

This patch series moves some files and directories around but is only code motion (or supposed to be). A new directory, common/, is created for all of the common code which is currently shared in random ways between parts of the project. And src/ becomes lib/ (the largest change, but mostly mechanical). In full this series makes the following changes: src/libprotocol -> common/protocol

Previous patch series was posted here: https://www.redhat.com/archives/libguestfs/2017-January/msg00059.html v2 simply extends this patch series to cover the extra directories common/edit, common/progress, common/windows and common/parallel. The only remaining item is to consider whether we should rename mllib to something else, mlcommon was my suggestion. Rich.

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw This is the port to Windows using native Windows APIs (not MSYS or Cygwin). This patch series is at the point where it basically now works. I can run the server with the memory plugin, and access it remotely using guestfish, creating filesystems and so on without any apparent problems. Nevertheless there are many

This creates libnbdkit.so as discussed in the following thread: https://www.redhat.com/archives/libguestfs/2020-March/thread.html#00203 test-delay-shutdown.sh fails for unclear reasons. This series starts by reverting "tests: Don't strand hung nbdkit processes" which is because several other tests fail randomly unless I revert this patch. I didn't investigate this yet so it

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw-nolib After a lot of work I have made the port to Windows work without using a separate library. Instead, on Windows only, we build an "import library" (library of stubs) which resolves references to nbdkit_* functions in the main program and fixes up the plugin, basically the first technique outlined in