2.0.13 build failure on NetBSD 7.1ish amd64

2.0.13 build failure on NetBSD 7.1ish amd64

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]


(I pretend to maintain guile in pkgsrc, a multi-os multi-os-version
multi-arch packaging system, and sometimes I actually get around to it.)

Due to

  https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-8605

I'm trying again to update from 2.0.12 to 2.0.13.  (I dimly remember
that I tried earlier and ran into trouble, and didn't get around to
becoming coherent enough to send a note.)  2.0.12 has been building fine
on the same system.

It looks like the very first run of the compiler is failing, on
ice-9/eval.scm, and that the new mkstemp! code is throwing an error.  I
am building as a normal user with a normal umask and my whole build tree
is that user.

In case the already-installed guile 2.0.12 was somehow leaking into the
build environment, I removed it (and guile 1.8), but I get the same
failure.

Any clues appreciated -- dropping printfs or gdb into the implementation
of mkstemp! does not seem likely to be the most effective approach.

build/system info

  NetBSD 7 from just before 7.1RC, but nothing radical has changed recently
  amd64
  gcc 4.8.5
  (in general, NetBSD is quite good about POSIX.)
  --without-threads, because boehm-gc in pkgsrc doesn't have threads

Strings with MKSTEMP from config.status:

  S["REPLACE_MKSTEMP"]="0"
  S["HAVE_MKSTEMPS"]="1"
  S["HAVE_MKSTEMP"]="1"
  S["HAVE_MKOSTEMPS"]="1"
  S["HAVE_MKOSTEMP"]="1"
  S["GNULIB_MKSTEMPS"]="0"
  S["GNULIB_MKSTEMP"]="0"
  S["GNULIB_MKOSTEMPS"]="0"
  S["GNULIB_MKOSTEMP"]="1"
  D["HAVE_MKOSTEMP"]=" 1"
  D["GNULIB_MKOSTEMP"]=" 1"
  D["GNULIB_TEST_MKOSTEMP"]=" 1"
  D["HAVE_RAW_DECL_MKOSTEMP"]=" 1"
  D["HAVE_RAW_DECL_MKOSTEMPS"]=" 1"
  D["HAVE_RAW_DECL_MKSTEMP"]=" 1"

end of build log:

gmake[2]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/lang/guile20/work/guile-2.0.13/libguile'
Making all in module
gmake[2]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/lang/guile20/work/guile-2.0.13/module'
  GUILEC ice-9/eval.go
  Backtrace:
  In unknown file:
  ?: 3 [apply-smob/1 #<boot-closure 67eba0 (_ _ _)> #t ...]
  ?: 2 [apply-smob/1 #<catch-closure 81df80>]
  ?: 1 [primitive-eval ((@ # %) (begin # # #))]
  ?: 0 [mkstemp! "ice-9/eval.go.XXXXXX" "wb"]

ERROR: Makefile:2235: recipe for target 'ice-9/eval.go' failed
gmake[2]: *** [ice-9/eval.go] Error 1
gmake[2]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/lang/guile20/work/guile-2.0.13/module'
Makefile:1838: recipe for target 'all-recursive' failed
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/lang/guile20/work/guile-2.0.13'
Makefile:1724: recipe for target 'all' failed
gmake: *** [all] Error 2
*** Error code 2

Stop.
make[1]: stopped in /u0/n0/gdt/NetBSD-current/pkgsrc/lang/guile20
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/lang/guile20

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 162 bytes --]

mkostemp portability issues

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]


Earlier I reported that 2.0.13 did not build on NetBSD.  Matt Wette
pointed me to a debbugs entry.  The issue seems to be that mkostemp is
not a POSIX-specified interface and the list of acceptable flags differs
on different platforms.

I have included the patch I just added to pkgsrc, which steals the patch
from the debbugs entry for Mac and adds a similar line for NetBSD.

Overall, I am unclear on the portability status of mkostemp.  I think
it's not specified by POSIX, and thus I wonder if guile is checking for
it before  using it, and what happens to scheme code if it isn't there.

And then there's the issue of differing flags.  I wonder what flags are
acually useful and if there is a core set that is supported more or less
everywhere.  Perhaps the Mac set is that set.  Generally guile tries to
avoid the OS details creeping into scheme code, and silently dropping
flags rather than erroring seems troublesome.  But I don't really
understand this issue well enough to have a firm opinion yet.



$NetBSD: patch-libguile_filesys.c,v 1.2 2017/02/21 02:32:00 gdt Exp $

When using mkostemp (an interface not defined by POSIX), restrict
flags to the set defined by the documentation of particular operating
systems.

See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24862#23 for discussion.

This patch has not yet been sent upstream.

--- libguile/filesys.c.orig	2016-12-15 00:03:33.000000000 +0000
+++ libguile/filesys.c
@@ -1486,6 +1486,15 @@ SCM_DEFINE (scm_i_mkstemp, "mkstemp!", 1
       mode_bits = scm_i_mode_bits (mode);
     }
 
+#ifdef __APPLE__
+  /* https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24862#23 */
+  open_flags &= O_APPEND|O_SHLOCK|O_EXLOCK|O_CLOEXEC;
+#endif
+#ifdef __NetBSD__
+  /* Restrict to list of flags documented in man page. */
+  open_flags = O_APPEND|O_DIRECT|O_SHLOCK|O_EXLOCK|O_SYNC|O_CLOEXEC;
+#endif
+
   SCM_SYSCALL (rv = mkostemp (c_tmpl, open_flags));
   if (rv == -1)
     SCM_SYSERROR;

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 162 bytes --]

Re: mkostemp portability issues

[Matt Wette]

> On Feb 20, 2017, at 6:39 PM, Greg Troxel <gdt@lexort.com> wrote:
> +  open_flags = O_APPEND|O_DIRECT|O_SHLOCK|O_EXLOCK|O_SYNC|O_CLOEXEC;

I think you meant `&=‘

Re: mkostemp portability issues

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]


Matt Wette <matt.wette@gmail.com> writes:

>> On Feb 20, 2017, at 6:39 PM, Greg Troxel <gdt@lexort.com> wrote:
>> +  open_flags = O_APPEND|O_DIRECT|O_SHLOCK|O_EXLOCK|O_SYNC|O_CLOEXEC;
>
> I think you meant `&=‘

Thanks, fixed.

Interestingly most of the tests passed with the wrong code.  (There is
an issue, but it seems  like a test artifact, and it's the same
with/without the fix.)


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 162 bytes --]