similar to: [PATCH] hivex: Don't build static library, .so.* symlinks for Python bindings

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

--- configure.ac | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 261c44c..6c019e4 100644 --- a/configure.ac +++ b/configure.ac @@ -237,8 +237,8 @@ PYTHON_PREFIX= PYTHON_VERSION= if test "x$PYTHON" != "xno"; then - PYTHON_PREFIX=`$PYTHON -c "import sys; print sys.prefix"` - PYTHON_VERSION=`$PYTHON

The code has been taken from specifically ac_python_devel.m4 published at <http://ac-archive.sf.net/>, it has turned out to be less error-prone on my Debian system. --- configure.ac | 46 ++++++++++++---------------------------------- 1 files changed, 12 insertions(+), 34 deletions(-) diff --git a/configure.ac b/configure.ac index b82a841..5805ddd 100644 --- a/configure.ac +++

Since some modules (`getopt', for example) may copy files into the build directory, `top_builddir/lib' is needed as well as `top_srcdir/lib'. -- GNU Gnulib manual, section 2.2 Initial import This fixes an in-tree build failure on a Debian/sid system (see below). hivexml could be built out-of-tree, but it turned out that due to a missing include path, in this case the

--- configure.ac | 2 +- images/Makefile.am | 5 +++-- lib/Makefile.am | 14 +++++++------- ocaml/Makefile.am | 3 ++- ocaml/t/hivex_300_fold.ml | 3 +-- python/run-python-tests | 25 ------------------------- python/run-python-tests.in | 25 +++++++++++++++++++++++++ 7 files changed, 39 insertions(+), 38 deletions(-) delete mode

Hello all, I've been testing hivexml in OS X, and came across an inconsistency in building. Some while back, I hit a snag with iconv in OS X, where basically this would happen when a hive of any sophistication (greater than hivex/images/small) was processed: >$ xml/hivexml images/large >test.xml >dyld: lazy symbol binding failed: Symbol not found: _iconv_open > Referenced from:

Hi all, The linking problem I found yesterday appears to be because of the built-in iconv in OS X. So, this is a request for patch or pointers: What needs to happen with configure.ac or the iconv.m4 macro file to link an iconv library _besides_ the one in /usr/local/lib? That's the tl;dr, full explanation follows. That library lacks the x86_64 architecture: $ file

This patch series improves, but does not complete, OS X support for hivex. There are several outstanding issues before hivexml and hivexsh can run: * hivexsh uses open_memstream, which doesn't exist in OS X as near as I can see. Unfortunately, I'm inexperienced with autoconf, so I'm not sure how to employ AC_CHECK_FUNCS([open_memstream]) to conditionally add 'sh' to the

Hi, libhivex seems to do a great job at parsing hives most of the time, but there are some issues with a few registry keys. These can be worked around in the application that uses libhivex, but I think it'd be better if libhivex handled these itself. 1. UTF16 string in REG_SZ that has garbage after the \0\0 There is code in hivex.c to handle this already but I think it has a typo: /*

Whilst cleaning up the lintian reports in preparation for the Debian/Ubuntu hivex package one of the issues is: E: libhivex-perl: binary-or-shlib-defines-rpath ./usr/lib/perl/5.10.1/auto/Win/Hivex/Hivex.so /tmp/buildd/hivex-1.2.1/perl/../lib/.libs I've temporarily dealt with this by using chrpath in the build and a rule to delete the RPATH from "auto/Win/Hivex/Hivex.so". I wonder

At least libpython2.7-dev and libpython3.3-dev on current Debian/unstable ship with pkg-config files. As with the pkg-config check for Lua, we check for versioned and an unversioned .pc files. --- configure.ac | 35 ++++++++++++++++++++--------------- python/Makefile.am | 2 +- 2 files changed, 21 insertions(+), 16 deletions(-) diff --git a/configure.ac b/configure.ac index

On Thu, May 16, Hilko Bengen wrote: > AC_MSG_RESULT([$PYTHON_VERSION]) > - > - AC_MSG_CHECKING([for Python include path]) > - if test -z "$PYTHON_INCLUDEDIR"; then > - python_path=`$PYTHON -c "import distutils.sysconfig; \ > - print (distutils.sysconfig.get_python_inc ());"` > -

Hi As my cross platform registry editor (FRED available from https://www.pinguin.lu (sorry for advertising but I couldn't resist ;-))) is evolving, I recently added write support to it. While under Linux everything worked nice, the Windblows build didn't. It seems that Windows opens files by default in text mode (O_TEXT) which is a problem. The attached patch adds the O_BINARY flag to

Thanks very much for the responses on my last three issues. I've incorporated the appropriate changes into the budding Debian package. I feel embarrassed to raise this one, but in the interests of shutting lintian up maybe this could be fixed at some point: I: hivex: spelling-error-in-manpage usr/share/man/man1/hivexregedit.1.gz reencode re-encode I: libhivex-perl: spelling-error-in-manpage

On Sun, Jun 16, 2013 at 02:55:29PM +0200, Olaf Hering wrote: > On Thu, May 16, Hilko Bengen wrote: > > > AC_MSG_RESULT([$PYTHON_VERSION]) > > - > > - AC_MSG_CHECKING([for Python include path]) > > - if test -z "$PYTHON_INCLUDEDIR"; then > > - python_path=`$PYTHON -c "import distutils.sysconfig; \ > > -

On Thu, Jun 27, 2013 at 11:29:28PM +0200, Daniel Gillen wrote: > Hi > > As my cross platform registry editor (FRED available from > https://www.pinguin.lu (sorry for advertising but I couldn't resist > ;-))) is evolving, I recently added write support to it. > > While under Linux everything worked nice, the Windblows build didn't. > > It seems that Windows

--- configure.ac | 15 +++++++++++++-- generator/generator.ml | 12 ++++++++++-- ruby/Makefile.am | 11 ++++++----- ruby/Rakefile.in | 2 +- ruby/run-ruby-tests | 4 ++-- 5 files changed, 32 insertions(+), 12 deletions(-) diff --git a/configure.ac b/configure.ac index 8651c7b..33c09db 100644 --- a/configure.ac +++ b/configure.ac @@ -312,8 +312,19 @@

--- python/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/python/Makefile.am b/python/Makefile.am index 5884762..82960d6 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -43,7 +43,7 @@ libguestfsmod_la_SOURCES = guestfs-py.c guestfs-py.h guestfs-py-byhand.c libguestfsmod_la_CFLAGS = -Wall -I$(PYTHON_INCLUDEDIR) \ -I$(top_srcdir)/src

On Wed, Oct 29, 2014 at 10:43:59AM -0500, Mahmoud Al-Qudsi wrote: > Hello all, > > I know that one of the original design goals of libhivex was to be > resilient to corrupt, invalid, or malicious registry hives. I've > encountered some undefined behavior in libhivex when attempting to open > registry files that are too small. I'm not sure if this is a known issue >

Add a bash function 'prepend' for intelligently prepending elements to paths. eg: prepend PYTHONPATH "/foo" would set PYTHONPATH to "/foo" or "/foo:<previous-contents-of-PYTHONPATH>" Tested by: (1) Building and testing libguestfs twice: first without libguestfs installed as a system library, and then with it installed. (2) Examining the output of