Hi I'm Doug Hoyte the developer of vmtouch. Thanks for the report.
I'd rather not specify -std=gnu99 in the default Makefile so as to ensure it's as portable as possible. Do you happen to know what _*_SOURCE defines would work for these platforms? I'm thinking of including basically the following at the top of vmtouch.c: #ifdef __gnu_hurd__ #define PATH_MAX 4096 <whatever _*_SOURCE defines are necessary for hurd> #endif #ifdef __FreeBSD_kernel__ <whatever _*_SOURCE defines are necessary for kfreebsd> #endif Does this make sense? vmtouch has been tested on ILP32 and LP64 systems. The warnings you are seeing appear to be from string.h not declaring common string routines such as strsep. Hopefully the _*_SOURCE defines you mention will address this. Thanks, Doug On Sun, 03 Sep 2017 11:49:49 -0400 "Aaron M. Ucko" <u...@debian.org> wrote:
Source: vmtouch Version: 1.3.0-1 Severity: important Tags: upstream Justification: fails to build from source Builds of vmtouch for hurd-i386 and kfreebsd-* (admittedly not release architectures) have been failing with errors and warnings involving undeclared identifiers. The actual errors are vmtouch.c:723:14: error: 'PATH_MAX' undeclared (first use in this function); did you mean 'INT8_MAX'? vmtouch.c:894:29: error: 'optarg' undeclared (first use in this function); did you mean 'va_arg'? vmtouch.c:909:11: error: 'optind' undeclared (first use in this function); did you mean 'optarg'? but many of the warnings are concerning as well, at least on kfreebsd-amd64 (where int is narrower than pointers). For kFreeBSD (__FreeBSD_kernel__), it should suffice to define various _*_SOURCE macros more broadly. For the Hurd (__gnu_hurd__), you will also need to account for the lack of a static PATH_MAX. Best practice there is to allocate a dynamic array based on pathconf(_PC_PATH_MAX), or you could simply supply a fallback definition (typically 4096). Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
