[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

since: FTBFS on hurd-i386

From: Svante Signell
Subject: since: FTBFS on hurd-i386
Date: Tue, 20 May 2014 14:45:42 +0200

Source: since
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd


Currently since fails to build from source on GNU/Hurd due to failed
tests. The problem is that dev_t is an unsigned integer, i.e. 4 bytes, 
on Hurd but since expects dev_t to be 8 bytes. Therefore define the
internal device d_dev to be of type "unsigned long long integer" to enable 

According to Emilio Pozuelo Monfort <pochu@debian.org> this is a bug in Hurd, 
since, see below (Message #10):
> Looking at why the string format is incorrect, I've found that 
> make_fmt_field()
> (the function that creates the format string) is called for that argument 
> with a
> dev_t argument, while the st_dev member of struct stat is not of type dev_t, 
> but
> of __fsid_t. This seems to be a POSIX violation (because sizeof(__fsid_t) !=
> sizeof(dev_t), so it would be a bug in Hurd and not in since.

This seems to be correct:
According to 

The stat structure shall contain at least the following members:

dev_t     st_dev     Device ID of device containing file. 

However /usr/include/i386-gnu/bits/stat.h shows:

struct stat
    __fsid_t st_fsid;           /* File system ID.  */
#define st_dev  st_fsid

and /usr/include/i386-gnu/bits/types.h:

__STD_TYPE __FSID_T_TYPE __fsid_t;      /* Type of file system IDs.  */
__STD_TYPE __DEV_T_TYPE __dev_t;        /* Type of device numbers.  */
#if __WORDSIZE == 32
# define __UQUAD_TYPE           __u_quad_t
#define __U32_TYPE              unsigned int
#if __WORDSIZE == 64
typedef long int __quad_t;
typedef unsigned long int __u_quad_t;
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;

with /usr/include/i386-gnu/bits/typesizes.h:

#define __FSID_T_TYPE           __UQUAD_TYPE
#define __DEV_T_TYPE            __U32_TYPE

So this should probably be reported as a Hurd bug. Perhaps there are
direct consequences of doing that change without careful regression

Anyway, attached is an updated dev_t.patch to make since working again
on GNU/Hurd.


Attachment: dev_t.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]