Bug#754792: libbfio: FTBFS on hurd-386

Pierre Chifflier pollux at debian.org
Thu Aug 21 19:36:44 UTC 2014

On Mon, Jul 14, 2014 at 01:15:26PM +0200, Svante Signell wrote:
> Source: libbfio
> Version: 20130507-1
> Severity: important
> Tags: patch
> User: debian-hurd at lists.debian.org
> Usertags: hurd
> Hello,
> libbfio fails to build from source due to usage of PATH_MAX,which is not
> defined on GNU/Hurd. The attached patch fixes usage of PATH_MAX as
> second argument to getcwd() by using calls to getcwd (NULL, 0) instead.
> Supporting (NULL, 0) as arguments is an extension to POSIX.1-2001 for
> libc4, libc5 and glibc, so most modern systems have it. In order to
> simplify the patch, only this version is implemented.

Hi Svante,

I just uploaded new upstream versions for libbfio and libewf.

Unfortunately, the patches you sent no longer apply, since the code has
changed. I had a quick look, but could not determine what would be the
proper way to fix the build on hurd (and probably kfreebsd).
If you have some time to look at the new version, it would be great so
the package could be fixed before the release.

Here are a few more comments/questions on the patch:

> Index: libbfio-20130507/libcpath/libcpath_path.c
> ===================================================================
> --- libbfio-20130507.orig/libcpath/libcpath_path.c
> +++ libbfio-20130507/libcpath/libcpath_path.c
> @@ -356,9 +356,6 @@ int libcpath_path_get_current_working_di
>  	}
>  #if defined( WINAPI )
>  	*current_working_directory_size = (size_t) _MAX_PATH;
> -#else
> -	*current_working_directory_size = (size_t) PATH_MAX;
> -#endif
>  	*current_working_directory = libcstring_narrow_string_allocate(
>  	                              *current_working_directory_size );

If I understand correctly, current_working_directory_size is now
uninitialized ? Shouldn't it be set to 0 explicitly ?

> @@ -387,7 +384,6 @@ int libcpath_path_get_current_working_di
> +	*current_working_directory = getcwd (NULL, 0);

The getcwd manpage says that the allocation of memory is an extension to
the POSIX.1-2001 standard, so it seems Linux-specific. Will this cause
any problem on other platforms (I suppose Hurd is OK, but what about
kFreeBSD ?).


More information about the forensics-devel mailing list