GNU Guile 3.0.9rc1 available for testing!

GNU Guile 3.0.9rc1 available for testing!

[Ludovic Courtès]

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

Hello Guilers!

(Cc’ing packagers I know; feel free to ping other packagers!)

I pushed the ‘v3.0.9rc1’ tag on the ‘main’ branch and uploaded the
tarballs produced by “make distcheck” from that tag:

  https://alpha.gnu.org/gnu/guile/guile-3.0.9rc1.tar.gz
  SHA256: f34dac704b388e16541dfca5305ee48da1e5bf8e43a899f1e7927cc7c888dc65

  https://alpha.gnu.org/gnu/guile/guile-3.0.9rc1.tar.lz
  SHA256: 25507afe7733ad72f14615e7b9d5f4c5cb5abcbaa880ef15edd083d7f333d6ee

  https://alpha.gnu.org/gnu/guile/guile-3.0.9rc1.tar.xz
  SHA256: 9590a56a31de60c11b673fbbc9d0166364e270e5f7c6890d3282272fcfb2e871

These files come with a detached OpenPGP signature (a ‘.sig’ file) made
with my key, 3CE464558A84FDC69DB40CFB090B11993D9AEBB5.

Please report any issues you may find.  I’m particularly interested in
portability regressions (NetBSD and other BSDs, macOS, MinGW, as well as
architectures other than x86_64).

The SONAME has been bumped to its value as it will appear in 3.0.9.

If nothing bad comes up, I propose publishing 3.0.9 in a week or so.

Thanks in advance!

Ludo’.

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

Re: GNU Guile 3.0.9rc1 available for testing!

[Thompson, David]

Hi Ludo,

On Fri, Jan 20, 2023 at 10:58 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Please report any issues you may find.  I’m particularly interested in
> portability regressions (NetBSD and other BSDs, macOS, MinGW, as well as
> architectures other than x86_64).

I was curious about the MinGW build, so I used a Guix command you
shared to build it:

guix build guile-next --with-git-url=guile-next=$HOME/Code/guile
--with-branch=guile-next=main --target=x86_64-w64-mingw32

I then copied the resulting /gnu/store directory somewhere writable,
copied over all the DLLs (libgc, libunistring, etc.) it needed from
/gnu/store into the 'bin' directory, and tried running with wine64 but
it failed:

```
$ guix shell wine64 -- wine64 guile.exe
MESA-INTEL: warning: Performance support disabled, consider sysctl
dev.i915.perf_stream_paranoid=0

0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
Mingw-w64 runtime failure:
32 bit pseudo relocation at 0000000140001568 out of range, targeting
0000000319370E80, yielding the value 00000001D936F914.

abnormal program termination
```

Maybe someone else would like to give it a shot? Or even try running
it on Windows?  I hadn't tried in years, but my last experience with a
Guile MinGW build required either disabling threads and JIT or trying
to apply various patches people had floating around. So, to see a
build complete with just the upstream source and without disabling
anything is very promising!

Thanks for all the hard work on the release!

- Dave

Re: GNU Guile 3.0.9rc1 available for testing!

[Jan Nieuwenhuizen]

Thompson, David writes:

Hello!

> On Fri, Jan 20, 2023 at 10:58 AM Ludovic Courtès <ludo@gnu.org> wrote:
>>
>> Please report any issues you may find.  I’m particularly interested in
>> portability regressions (NetBSD and other BSDs, macOS, MinGW, as well as
>> architectures other than x86_64).
>
> I was curious about the MinGW build, so I used a Guix command you
> shared to build it:
>
> guix build guile-next --with-git-url=guile-next=$HOME/Code/guile
> --with-branch=guile-next=main --target=x86_64-w64-mingw32

I've tried twice, but the build didn't finish -- too long silence
time somewhere?  Last time it got to

    ...
    wrote `scripts/generate-autoload.go'
      BOOTSTRAP(stage0) GUILEC scripts/help.go
    wrote `scripts/help.go'
      BOOTSTRAP(stage0) GUILEC scripts/lint.go

where it hangs, the build server showing nothing no guix-build-* in
/tmp, and a rebuild doesn't fetch the built package.  So yeah, dunno.

> I then copied the resulting /gnu/store directory somewhere writable,
> copied over all the DLLs (libgc, libunistring, etc.) it needed from
> /gnu/store into the 'bin' directory, and tried running with wine64 but
> it failed:

Yeah, I've been using something like

WINEPATH=$(guix shell wine64 -- winepath -w                                     \
    $(echo $(guix gc -R                                                         \
                  $(GUIX_PACKAGE_PATH=guix guix build                           \
                                     --target=x86_64-w64-mingw32 guile-mingw))) \
               | sed 's,$,/bin,g' | tr '\n' ';')                                \
        guix shell wine64 -- wine                                               \
        $(GUIX_PACKAGE_PATH=guix guix build --target=x86_64-w64-mingw32         \
                           guile-mingw)/bin/guile.exe                           \
        -c '(format #t "Hello  ~a world!\n" %host-type)'

that's on the wip-mingw branch that has a guile-mingw package in a
guix/

> $ guix shell wine64 -- wine64 guile.exe
[..]
> Mingw-w64 runtime failure:
> 32 bit pseudo relocation at 0000000140001568 out of range, targeting
> 0000000319370E80, yielding the value 00000001D936F914.
>
> abnormal program termination
> ```

Yeah, you need at least

    76950b428 Support for x86_64-w64-mingw32.

or something similar, or another approach for addressing the
SIZEOF_LONG==4 issue on MinGW.  And compile with --disable-jit, AFAIK
nobody got that to work just yet.

> Thanks for all the hard work on the release!

+1

Greetings,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://lilypond.org
Freelance IT https://JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: GNU Guile 3.0.9rc1 available for testing!

[Ludovic Courtès]

Hi Jan,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Yeah, you need at least
>
>     76950b428 Support for x86_64-w64-mingw32.
>
> or something similar, or another approach for addressing the
> SIZEOF_LONG==4 issue on MinGW.

Oh sorry, I had completely overlooked that patch (and branch).

I’m hesitant about applying it at this late stage, also because I
haven’t thought about the possible choices and implications.  Maybe this
will have to wait until the next round (bah!)?

> And compile with --disable-jit, AFAIK nobody got that to work just
> yet.

OK.

Thanks for the heads-up!

Ludo’.

Re: GNU Guile 3.0.9rc1 available for testing!

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hi Ludo,

> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>
>> Yeah, you need at least
>>
>>     76950b428 Support for x86_64-w64-mingw32.
>>
>> or something similar, or another approach for addressing the
>> SIZEOF_LONG==4 issue on MinGW.
>
> Oh sorry, I had completely overlooked that patch (and branch).

No problem.  Mike has been looking into this as well.  Also, there are
commits that should probably be squashed into this, such as

    9a29293a8 More long integer fixes for x86_64-w64-mingw32
    46bb667f2 MinGW 64: fixes hash out-of-range error for 64-bit negative numbers

> I’m hesitant about applying it at this late stage, also because I
> haven’t thought about the possible choices and implications.  Maybe this
> will have to wait until the next round (bah!)?

Yeah, that seems wise.

Also there is still an unresolved problem with file-name-convention.

We probably want

    2d82b49cf mingw: canonicalize-path: Also canonicalize drive letter and '/'.

Also, during a (cross)build, file-name-convention from build host is
used/assumed.  I tried to creat a fix

   9bfd0b544 squash! Fix 'absolute-file-name?' and others for cross-build to MinGW.
   96597fa21 Fix 'absolute-file-name?' and others for cross-build to MinGW.

but iirc, Mike found a problem with these.  Hairy stuff.

>> And compile with --disable-jit, AFAIK nobody got that to work just
>> yet.
>
> OK.
>
> Thanks for the heads-up!

You're welcome, it's great that guile at least builds with MintGW now.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: GNU Guile 3.0.9rc1 available for testing!

[Aleix Conchillo Flaqué]

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

On Fri, Jan 20, 2023 at 7:58 AM Ludovic Courtès <ludo@gnu.org> wrote:

> Hello Guilers!
>
> (Cc’ing packagers I know; feel free to ping other packagers!)
>
> I pushed the ‘v3.0.9rc1’ tag on the ‘main’ branch and uploaded the
> tarballs produced by “make distcheck” from that tag:
>
>
Awesome! Thank you!

Not because I worked on it :-), but missing JIT support on Apple Silicon
chips in the NEWS, which makes Guile *fast* on that hardware.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505

Best,

Aleix

[-- Attachment #2: Type: text/html, Size: 1371 bytes --]

Re: GNU Guile 3.0.9rc1 available for testing!

[Ludovic Courtès]

Hola!

Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis:

> Not because I worked on it :-), but missing JIT support on Apple Silicon
> chips in the NEWS, which makes Guile *fast* on that hardware.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505

Oops, my bad; added to NEWS!

You confirm that building from the tarball still works, right?

Thanks,
Ludo’.

Re: GNU Guile 3.0.9rc1 available for testing!

[Aleix Conchillo Flaqué]

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

On Mon, Jan 23, 2023 at 2:45 AM Ludovic Courtès <ludo@gnu.org> wrote:

> Hola!
>
>
Hola!

> Aleix Conchillo Flaqué <aconchillo@gmail.com> skribis:
>
> > Not because I worked on it :-), but missing JIT support on Apple Silicon
> > chips in the NEWS, which makes Guile *fast* on that hardware.
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505
>
> Oops, my bad; added to NEWS!
>
>
Mmm.... still don't see it.


> You confirm that building from the tarball still works, right?
>
>
Actually, it doesn't. Just tried it. I'll see if I have time tonight to fix
it. Hang tight!

  CC       libguile_3.0_la-posix.lo
posix.c:109:9: error: cannot take the address of an rvalue of type 'int'
verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/wait.h:144:27:
note: expanded from macro 'WEXITSTATUS'
#define WEXITSTATUS(x)  ((_W_INT(x) >> 8) & 0x000000ff)
                          ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/wait.h:131:34:
note: expanded from macro '_W_INT'
#define _W_INT(w)       (*(int *)&(w))  /* convert union wait to int */
                                 ^
../lib/verify.h:305:32: note: expanded from macro 'verify'
# define verify(R) _GL_VERIFY (R, "verify (" #R ")", -)
                   ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~

[-- Attachment #2: Type: text/html, Size: 3075 bytes --]

Re: GNU Guile 3.0.9rc1 available for testing!

[Greg Troxel]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guilers!
>
> (Cc’ing packagers I know; feel free to ping other packagers!)

I dropped the CC as I suspect all are on guile-devel.

> Please report any issues you may find.  I’m particularly interested in
> portability regressions (NetBSD and other BSDs, macOS, MinGW, as well as
> architectures other than x86_64).

Thanks for being welcoming to portability issues.

I am building from git via autogen first.  I'll try the tarball next.

(We do have a JIT/PaX issue on NetBSD which is worked around in
packaging, but that's not new and I don't want to ask you to hold this
micro over it.  I'll write a more coherent note about that separately.)

The build failed with:

----------------------------------------
make  all-recursive
Making all in lib
make  all-recursive
Making all in meta
Making all in libguile
make  all-am
  CC       libguile_3.0_la-posix.lo
In file included from ../config.h:3293:0,
                 from ../../libguile/posix.c:24:
../../libguile/posix.c:109:9: error: lvalue required as unary '&' operand
 verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
         ^
../../lib/verify.h:305:20: note: in expansion of macro '_GL_VERIFY'
 # define verify(R) _GL_VERIFY (R, "verify (" #R ")", -)
                    ^~~~~~~~~~
../../libguile/posix.c:109:1: note: in expansion of macro 'verify'
 verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
 ^~~~~~
../../libguile/posix.c:109:9: error: expression in static assertion is not an integer
 verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
         ^
../../lib/verify.h:305:20: note: in expansion of macro '_GL_VERIFY'
 # define verify(R) _GL_VERIFY (R, "verify (" #R ")", -)
                    ^~~~~~~~~~
../../libguile/posix.c:109:1: note: in expansion of macro 'verify'
 verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
 ^~~~~~
*** Error code 1

Stop.
make[3]: stopped in /home/n0/gdt/SOFTWARE/GUILE/guile/BUILD/libguile
*** Error code 1

Stop.
make[2]: stopped in /home/n0/gdt/SOFTWARE/GUILE/guile/BUILD/libguile
*** Error code 1

Stop.
make[1]: stopped in /home/gdt/SOFTWARE/GUILE/guile/BUILD
*** Error code 1

Stop.
make: stopped in /home/gdt/SOFTWARE/GUILE/guile/BUILD
----------------------------------------

NetBSD has:

  /usr/include/sys/wait.h:#define WEXITSTATUS(x)  ((int)(((unsigned int)_W_INT(x)) >> 8) & 0xff)

which looks similar enough at first glance.


Next I'll try the tarball in pkgsrc.

Re: GNU Guile 3.0.9rc1 available for testing!

[lloda]

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


This looks like https://debbugs.gnu.org/60971 <https://debbugs.gnu.org/60971> on mac os.

Regards

	Daniel



[-- Attachment #2: Type: text/html, Size: 617 bytes --]

Re: GNU Guile 3.0.9rc1 available for testing!

[Greg Troxel]

lloda <lloda@sarc.name> writes:

> This looks like https://debbugs.gnu.org/60971 <https://debbugs.gnu.org/60971> on mac os.

Yes, it does.

My quick reaction is that if the POSIX-required macros operation on
system types that might be struct, then faking up ints for testing is
unsound.

Maybe only do verify if guile has to define macros, and don't try to
test the OS?

Re: GNU Guile 3.0.9rc1 available for testing!

[Ludovic Courtès]

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

Hi,

Greg Troxel <gdt@lexort.com> skribis:

> lloda <lloda@sarc.name> writes:
>
>> This looks like https://debbugs.gnu.org/60971 <https://debbugs.gnu.org/60971> on mac os.
>
> Yes, it does.
>
> My quick reaction is that if the POSIX-required macros operation on
> system types that might be struct, then faking up ints for testing is
> unsound.
>
> Maybe only do verify if guile has to define macros, and don't try to
> test the OS?

So something like the patch below?

Thanks,
Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 314 bytes --]

diff --git a/libguile/posix.c b/libguile/posix.c
index 74c743119..0b1fe2637 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -105,8 +105,8 @@
 # else
 #  define W_EXITCODE(ret, sig)   ((ret) << 8 | (sig))
 # endif
-#endif
 verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
+#endif
 
 
 #include <signal.h>

Re: GNU Guile 3.0.9rc1 available for testing!

[lloda]

lgtm, no other issues on mac os.

thanks

  Daniel

Re: bug#60971: build failure of v3.0.9rc1 on mac os 12.6

[Ludovic Courtès]

lloda <lloda@sarc.name> skribis:

> lgtm, no other issues on mac os.

Awesome, pushed as 9b20ca275dba758a194073936cde7c95311bd51e.

Ludo’.

Re: GNU Guile 3.0.9rc1 available for testing!

[Aleix Conchillo Flaqué]

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

On Mon, Jan 23, 2023 at 2:48 AM Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> Greg Troxel <gdt@lexort.com> skribis:
>
> > lloda <lloda@sarc.name> writes:
> >
> >> This looks like https://debbugs.gnu.org/60971 <
> https://debbugs.gnu.org/60971> on mac os.
> >
> > Yes, it does.
> >
> > My quick reaction is that if the POSIX-required macros operation on
> > system types that might be struct, then faking up ints for testing is
> > unsound.
> >
> > Maybe only do verify if guile has to define macros, and don't try to
> > test the OS?
>
> So something like the patch below?
>

Oh, I missed the other report. Yes, this works on macOS as just reported by
Daniel. No other issues.

Aleix

[-- Attachment #2: Type: text/html, Size: 1706 bytes --]

Re: GNU Guile 3.0.9rc1 available for testing!

[Greg Troxel]

Ludovic Courtès <ludo@gnu.org> writes:

> So something like the patch below?
>
> Thanks,
> Ludo’.
>
> diff --git a/libguile/posix.c b/libguile/posix.c
> index 74c743119..0b1fe2637 100644
> --- a/libguile/posix.c
> +++ b/libguile/posix.c
> @@ -105,8 +105,8 @@
>  # else
>  #  define W_EXITCODE(ret, sig)   ((ret) << 8 | (sig))
>  # endif
> -#endif
>  verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
> +#endif
>  
>  
>  #include <signal.h>

I see you pushed that to master and I have done a full build from master
with the pkgsrc JIT workarounds.  It mostly worked and I got this, which
may be because I purged not-needed packages (but the guile build didn't
complain at configure or check time, like it did for missing gperf which
I put back).  Or maybe I just haven't gotten this far with 3.0.9-ish.

    CC       test_foreign_object_c-test-foreign-object-c.o
    CCLD     test-foreign-object-c
  ld: ../../libguile/.libs/libguile-3.0.so: warning: warning: tmpnam() possibly used unsafely, use mkstemp() or mkdtemp()
  ld: /tmp//ccOnwVqC.ltrans0.ltrans.o: in function `finalizer':
  /home/n0/gdt/SOFTWARE/GUILE/guile/BUILD/test-suite/standalone/../../../test-suite/standalone/test-foreign-object-c.c:42: undefined reference to `rpl_free'

LTO seems enabled, but I see ranlib complaints in the build log.  I know
LTO is not new in this micro.  Maybe I'm trailing edge but it seems
slightly like living dangerously if not known to be ok -- but
--disable-lto is easy enough so no worries.

I kicked off a new build with --disable-lto, and that succeeded.  Tests
are not entirely ok, but that's not a regression.  I used the distfile
as a faux release to build guile pkgsrc from, and that built fine and
runs.

There are some issues for me to work through eventually, but for 3.0.9 I
have arrived at being ok with you releasing the current state of git
master (3 commits past rc1) as not having anything I can claim is a
regression and not anything I can't work around as before.

Greg

Re: GNU Guile 3.0.9rc1 available for testing!

[Ludovic Courtès]

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

Hi Greg,

Greg Troxel <gdt@lexort.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> So something like the patch below?
>>
>> Thanks,
>> Ludo’.
>>
>> diff --git a/libguile/posix.c b/libguile/posix.c
>> index 74c743119..0b1fe2637 100644
>> --- a/libguile/posix.c
>> +++ b/libguile/posix.c
>> @@ -105,8 +105,8 @@
>>  # else
>>  #  define W_EXITCODE(ret, sig)   ((ret) << 8 | (sig))
>>  # endif
>> -#endif
>>  verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
>> +#endif
>>  
>>  
>>  #include <signal.h>
>
> I see you pushed that to master and I have done a full build from master
> with the pkgsrc JIT workarounds.  It mostly worked and I got this, which
> may be because I purged not-needed packages (but the guile build didn't
> complain at configure or check time, like it did for missing gperf which
> I put back).  Or maybe I just haven't gotten this far with 3.0.9-ish.
>
>     CC       test_foreign_object_c-test-foreign-object-c.o
>     CCLD     test-foreign-object-c
>   ld: ../../libguile/.libs/libguile-3.0.so: warning: warning: tmpnam() possibly used unsafely, use mkstemp() or mkdtemp()
>   ld: /tmp//ccOnwVqC.ltrans0.ltrans.o: in function `finalizer':
>   /home/n0/gdt/SOFTWARE/GUILE/guile/BUILD/test-suite/standalone/../../../test-suite/standalone/test-foreign-object-c.c:42: undefined reference to `rpl_free'

I believe this is because these C files in test-suite/standalone end up
including Gnulib headers (like <stdlib.h>), which really shouldn’t be
necessary, without linking against libgnu.a.

I believe the patch below fixes that.

[...]

> There are some issues for me to work through eventually, but for 3.0.9 I
> have arrived at being ok with you releasing the current state of git
> master (3 commits past rc1) as not having anything I can claim is a
> regression and not anything I can't work around as before.

Sounds good.

Thanks for your feedback!

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1205 bytes --]

diff --git a/test-suite/standalone/Makefile.am b/test-suite/standalone/Makefile.am
index 547241afa..0b5d05ddb 100644
--- a/test-suite/standalone/Makefile.am
+++ b/test-suite/standalone/Makefile.am
@@ -1,7 +1,7 @@
 ## Process this file with automake to produce Makefile.in.
 ##
 ## Copyright 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-##   2011, 2012, 2013, 2014, 2020, 2021, 2022 Free Software Foundation, Inc.
+##   2011, 2012, 2013, 2014, 2020, 2021, 2022, 2023 Free Software Foundation, Inc.
 ##
 ## This file is part of GUILE.
 ##
@@ -39,8 +39,7 @@ TESTS_ENVIRONMENT =						\
 
 ## Check for headers in $(srcdir) and build dir before $(CPPFLAGS), which
 ## may point us to an old, installed version of guile.
-AM_CPPFLAGS = -I$(top_srcdir) -I$(top_builddir) \
-	      -I$(top_srcdir)/lib -I$(top_builddir)/lib
+AM_CPPFLAGS = -I$(top_srcdir) -I$(top_builddir)
 
 test_cflags =					\
   -I$(top_srcdir)/test-suite/standalone -I.	\
@@ -55,7 +54,7 @@ LIBGUILE_LDADD =							\
 
 
 snarfcppopts =						\
-  -I$(top_srcdir) -I$(top_srcdir)/lib -I$(top_builddir)/lib -I$(top_builddir) \
+  -I$(top_srcdir) -I$(top_builddir)			\
   -I. $(DEFS) $(DEFAULT_INCLUDES) $(CPPFLAGS) $(CFLAGS)
 
 SUFFIXES = .x

Re: GNU Guile 3.0.9rc1 available for testing!

[Greg Troxel]

My second approach is using the rc tarball in pkgsrc.  I had to patch
out the verify call.  pkgsrc already works around PaX issues mostly, via
paxctl on things that do jit, after build and before use, and by

  --- libguile/loader.c.orig      2018-01-08 16:21:04.790894906 +0000
  +++ libguile/loader.c
  @@ -484,7 +484,7 @@ map_file_contents (int fd, size_t len, i
     char *data;

   #ifdef HAVE_SYS_MMAN_H
  -  data = mmap (NULL, len, PROT_READ, MAP_PRIVATE, fd, 0);
  +  data = mmap (NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
     if (data == MAP_FAILED)
       SCM_SYSERROR;
     *is_read_only = 1;

because (something like, am fuzzy) mprotect (at least ours) can only
reduce not add permissions.  I still don't understand why this isn't a
more widespread issue.

With the rc tarball, the build almost works, and now stops at:

  Making all in guile-readline
  gmake[2]: Entering directory '/tmp/work/lang/guile30/work/guile-3.0.9rc1/guile-readline'
  /usr/pkg/bin/gmake  all-am
  gmake[3]: Entering directory '/tmp/work/lang/guile30/work/guile-3.0.9rc1/guile-readline'
  gmake[3]: *** No rule to make target 'ice-9/readline.scm', needed by 'ice-9/readline.go'.  Stop.
  gmake[3]: Leaving directory '/tmp/work/lang/guile30/work/guile-3.0.9rc1/guile-readline'
  gmake[2]: *** [Makefile:1984: all] Error 2
  gmake[2]: Leaving directory '/tmp/work/lang/guile30/work/guile-3.0.9rc1/guile-readline'
  gmake[1]: *** [Makefile:2152: all-recursive] Error 1
  gmake[1]: Leaving directory '/tmp/work/lang/guile30/work/guile-3.0.9rc1'
  gmake: *** [Makefile:2038: all] Error 2
  *** Error code 2

with or without -j2.   I see ice-9/readline.scm in git but not in the
rc tarball.

Re: GNU Guile 3.0.9rc1 available for testing!

[Greg Troxel]

Greg Troxel <gdt@lexort.com> writes:

> with or without -j2.   I see ice-9/readline.scm in git but not in the
> rc tarball.

and, in guile-readline/Makefile.am I see

  if HAVE_READLINE

  SOURCES += ice-9/readline.scm

and I don't see an else with EXTRA_DIST.  I think it's a bug for make
dist contents to vary with whether or not libs are available on the
local system.

Re: GNU Guile 3.0.9rc1 available for testing!

[Ludovic Courtès]

Hi,

Greg Troxel <gdt@lexort.com> skribis:

> and, in guile-readline/Makefile.am I see
>
>   if HAVE_READLINE
>
>   SOURCES += ice-9/readline.scm
>
> and I don't see an else with EXTRA_DIST.  I think it's a bug for make
> dist contents to vary with whether or not libs are available on the
> local system.

Oops, good catch.  I’ve fixed the machinery to require ‘HAVE_READLINE’
when running ‘make dist’ (that sounded more reliable than duplicating
the list of source files in ‘guile-readline/Makefile.am’).

Thanks,
Ludo’.

Re: GNU Guile 3.0.9rc1 available for testing!

[Ludovic Courtès]

Greg Troxel <gdt@lexort.com> skribis:

> My second approach is using the rc tarball in pkgsrc.  I had to patch
> out the verify call.  pkgsrc already works around PaX issues mostly, via
> paxctl on things that do jit, after build and before use, and by
>
>   --- libguile/loader.c.orig      2018-01-08 16:21:04.790894906 +0000
>   +++ libguile/loader.c
>   @@ -484,7 +484,7 @@ map_file_contents (int fd, size_t len, i
>      char *data;
>
>    #ifdef HAVE_SYS_MMAN_H
>   -  data = mmap (NULL, len, PROT_READ, MAP_PRIVATE, fd, 0);
>   +  data = mmap (NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
>      if (data == MAP_FAILED)
>        SCM_SYSERROR;
>      *is_read_only = 1;
>
> because (something like, am fuzzy) mprotect (at least ours) can only
> reduce not add permissions.  I still don't understand why this isn't a
> more widespread issue.

My understanding is that the expectation of being able to later mprotect
that mapping to make it writable is a valid one per POSIX.  Quoth
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/mprotect.html>:

  If PROT_WRITE is specified, the application shall ensure that it has
  opened the mapped objects in the specified address range with write
  permission, unless MAP_PRIVATE was specified in the original mapping,
  regardless of whether the file descriptors used to map the objects
  have since been closed.

Here the original file descriptors are O_RDONLY, but the mapping is
MAP_PRIVATE.

I’m not sure how to best address that.

Thoughts?

Ludo’.

Re: GNU Guile 3.0.9rc1 available for testing!

[Greg Troxel]

Ludovic Courtès <ludo@gnu.org> writes:

> My understanding is that the expectation of being able to later mprotect
> that mapping to make it writable is a valid one per POSIX.  Quoth
> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mprotect.html>:
>
>   If PROT_WRITE is specified, the application shall ensure that it has
>   opened the mapped objects in the specified address range with write
>   permission, unless MAP_PRIVATE was specified in the original mapping,
>   regardless of whether the file descriptors used to map the objects
>   have since been closed.
>
> Here the original file descriptors are O_RDONLY, but the mapping is
> MAP_PRIVATE.
>
> I’m not sure how to best address that.
>
> Thoughts?

Thanks.  Definitely, let's keep this separate from 3.0.9.  It is not new
and it is easy for me to keep the workaround in pkgsrc.   I will consult
with our POSIX lawyers and see what comes of that.   If it turns out, as
seems likely, that this is a NetBSD bug, it will almost certainly be
fixed.

Either way, it might be good to have an ifdef with the workaround,  but
maybe with pkgsrc and few building not from pkgsrc, especially on
systems that wouldn't get the likely fix, it might be better to just not
do anything.  I think we should wait until we understand the POSIX
issues better.