similar to: hivex: Bug: RPATH in Perl SO

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

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

On 06/06/2013 18:04, Hans Wennborg wrote:> It's probably PR12517. > > Looking at the clang binary, it's got a /home/ dir in RPATH: > > $ objdump -p clang+llvm-3.3rc3-Ubuntu-12.04.2-x86_64/bin/clang | grep RPATH > RPATH > $ORIGIN/../lib:/home/aadgrand/tmp/LLVM-3.3rc3/rc3/Phase3/Release+Asserts/llvmCore-3.3-rc3.obj/Release+Asserts/bin To avoid such behavior [1] , in

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: /*

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:

--- 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

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

Hello, First and foremost - awesome library, beautiful code. Thank you! If I may be so bold as to make my first post to the mailing list a request for an API change, I have attached a patch for a new function in the hivex library that implements obtaining a handle to a "deep" node, allowing the user to enter a path like "SOFTWARE\Intel\Infinst\Uninstall" with only a previous

hivexml on OS X was failing with a symbol-not-found error while dynamically linking. Adding iconv to libhivex fixes the issue and lets OS X process 'images/large' with hivexml. It took careful iconv autotool additions to get compilation working in Fedora as well, but these two lines build and run on OS X 10.6 and 10.8, and Fedora 17 and 18. Unfortunately, a separate issue is revealed

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

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 per-se or not, so I figured I'd ask here on the mailing list before I jumped in and started adding

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

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

On Oct 29, 2014, at 3:39 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > >> Or is it expected that certain sanity checks would be performed prior to >> passing along any files to libhivex? What would those checks be? > > No, hivex should definitely have those checks. > > I'll have a proper look at this in the morning. > > Thanks, > > Rich.

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

The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be looking at

On 07/30/2014 10:06 AM, Larry Evans wrote: > On 07/30/2014 12:35 AM, Ben Pope wrote: >> On Wednesday, July 30, 2014 01:31 PM, Ben Pope wrote: >> >>> ldd your_built_clang | grep libstdc++ >>> chrpath -l your_built_clang >> >> Hmm, where "your_built_clang" should be the actual failing executable: >>

--- python/Makefile.am | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/python/Makefile.am b/python/Makefile.am index 8599863..89e66f8 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -36,6 +36,7 @@ libhivexmod_la_SOURCES = hivex-py.c libhivexmod_la_CFLAGS = -Wall -I$(PYTHON_INCLUDEDIR) \ -I$(top_srcdir)/lib -I$(top_builddir)/lib

It's probably PR12517. Looking at the clang binary, it's got a /home/ dir in RPATH: $ objdump -p clang+llvm-3.3rc3-Ubuntu-12.04.2-x86_64/bin/clang | grep RPATH RPATH $ORIGIN/../lib:/home/aadgrand/tmp/LLVM-3.3rc3/rc3/Phase3/Release+Asserts/llvmCore-3.3-rc3.obj/Release+Asserts/bin This will slow things down if the system tries to automount /home/aadgrand. Maybe we should merge r182559

Hi, This series updates to the latest gnulib, after making most of its "make syntax-check" tests pass. There are still a few tests (listed in cfg.mk) that are simply skipped. To enable one, just remove its test name from the list of tests to skip and run "make syntax-check". [PATCH hivex 01/14] maint: add cfg.mk to prepare for syntax-check [PATCH hivex 02/14] maint: remove