bug#25921: pkgsrc patches: Dragonfly support
On Wed 01 Mar 2017 21:27, Thomas Klausner writes: > $NetBSD: patch-lib_signal.in.h,v 1.1 2016/12/03 03:15:33 marino Exp $ > > DragonFly support. > > --- lib/signal.in.h.orig 2016-06-29 09:12:27 UTC > +++ lib/signal.in.h > @@ -61,6 +61,7 @@ > #if (@GNULIB_PTHREAD_SIGMASK@ || defined GNULIB_POSIXCHECK) \ > && ((defined __APPLE__ && defined __MACH__) \ > || defined __FreeBSD__ || defined __OpenBSD__ || defined __osf__ \ > +|| defined __DragonFly__ \ > || defined __sun || defined __ANDROID__) \ > && ! defined __GLIBC__ > # include > This file comes from gnulib. Can you send this patch there? bug-gnu...@gnu.org. That way you will fix it once and reap the benefits many places. > $NetBSD: patch-libguile_threads.c,v 1.1 2016/12/03 03:15:33 marino Exp $ > > DragonFly support. > > --- libguile/threads.c.orig 2016-06-20 20:35:06 UTC > +++ libguile/threads.c > @@ -2252,7 +2252,7 @@ scm_ia64_ar_bsp (const void *opaque) >return (void *) ctx->uc_mcontext.sc_ar_bsp; > } > # endif /* linux */ > -# ifdef __FreeBSD__ > +# if defined __FreeBSD__ || defined __DragonFly__ > # include > void * This is for ia64 support which AFAIU DragonFly doesn't do; I think you can drop this one. Closing this one as I think there's nothing for me to do here. Andy
bug#25922: pkgsrc patches: older Darwin support
On Wed 01 Mar 2017 21:28, Thomas Klausner writes:
> Another pkgsrc patch concerns itself with supporting older Darwin
> releases, attached. Can you please merge it?
> Thomas
>
> $NetBSD: patch-libguile_stime.c,v 1.1 2016/10/19 14:56:17 adam Exp $
>
> Fix building on Darwin.
>
> --- libguile/stime.c.orig 2016-10-19 07:55:02.0 +
> +++ libguile/stime.c
> @@ -828,7 +828,7 @@ scm_init_stime()
>if (clock_gettime (CLOCK_REALTIME, &posix_real_time_base) == 0)
> get_internal_real_time = get_internal_real_time_posix_timer;
>
> -#ifdef HAVE_POSIX_CPUTIME
> +#if defined(HAVE_POSIX_CPUTIME) && defined(HAVE_CLOCK_GETCPUCLOCKID)
>{
> clockid_t dummy;
>
I believe this was fixed in 2.1.6, so I think you can drop this one.
Andy
bug#25923: pkgsrc patches: improve mkostemp support
On Wed 01 Mar 2017 21:29, Thomas Klausner writes: > --- libguile/filesys.c.orig 2016-12-15 00:03:33.0 + > +++ 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; I believe this was fixed in 2.1.6 as well so you can drop this one too. Cheers, Andy
bug#25912: 2.1.7 segfaults on cygwin
On Fri 03 Mar 2017 15:32, Mike Gran writes: > I also can replicate the Cygwin problem as originally described. I understand that with the fix in 2.1.8, that things are working correctly now; closing the report. Thanks for the sleuthing, szgyg and Mike! Andy
bug#25791: address argument to atomic operation must be a pointer to _Atomic type with 2.1.7 on macOS
On Wed 01 Mar 2017 17:43, Andy Wingo writes:
> On Sun 19 Feb 2017 09:41, ilove zfs writes:
>
>> On macOS 10.11 and 10.12 building with Xcode 8, guile 2.1.7 fails to
>> compile with several errors saying "address argument to atomic
>> operation must be a pointer to _Atomic type." I
>> can avoid this by setting ac_cv_header_stdatomic_h=no.
>>
>> Build logs here:
>> https://gist.github.com/ilovezfs/b18b7e6160e0a4c5da297cc430961f63
>> https://gist.github.com/57e1513e03ede26dc97c0f63eaad3a98
>>
>> Build failure is
>> ```
>> CC libguile_2.2_la-arrays.lo
>> CC libguile_2.2_la-async.lo
>> In file included from async.c:27:
>> ../libguile/atomics-internal.h:37:10: error: address argument to
>> atomic operation must be a pointer to _Atomic type ('gl_uint32_t *'
>> (aka 'unsigned int *') invalid)
>> return atomic_fetch_sub (loc, arg);
>> ^ ~~~
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.0.0/include/stdatomic.h:149:43:
>> note: expanded from macro 'atomic_fetch_sub'
>> #define atomic_fetch_sub(object, operand) __c11_atomic_fetch_sub(object,
>> operand, __ATOMIC_SEQ_CST)
>> ```
>> and several similar errors.
>>
>> Previously (as of guile 2.1.4) I had been able to work around the issue
>> without setting ac_cv_header_stdatomic_h=no with this patch:
>> https://raw.githubusercontent.com/ilovezfs/formula-patches/d2798a468346a7a28fbcd1c8aa3c1ccd5627b03f/guile/guile-atomic-type.patch
>>
>> However, the patch is no longer sufficient since now void** is one the types
>> needing _Atomic, which isn't allowed.
>
> Any ideas here? Sure would be nice to release a Guile with atomics that
> compiles with clang.
Fixed in 2.1.8 I think.
Andy
bug#24657: Autoconf macro GUILE_PROGS only looks for guile without version suffix even if given version - patch included
Found a bug in the modifications you made. Sorry for not catching this before it got included into the Guile 2.1.8 release. When constructing the candidates for the guile executable (_guile_candidates), the version numbers essentially get reverse. This is not noticeable for 2.2 since 2.2 reversed is still 2.2. But it is a major issue for Guile 2.0.x and 1.8.x where 0.2 and 8.1 get generated meaning the right executables could be missed. For the current version of GUILE_PROGS, looking for 2.0 results in the following candidates guile-0.2 guile0.2 guile-2 guile2 guile and for 1.8 guile-8.1 guile8.1 guile-1 guile1 guile The fix is luckily pretty trivial. A patch is attached. For convenience of anyone trying to reproduce this bug, here are two shell scripts that will take the version as the first input argument and return the generated guile executable candidates. The version with the bug is #!/bin/sh _guile_required_version=$1 _guile_candidates=guile _tmp= for v in `echo "$_guile_required_version" | tr . ' '`; do if test -n "$_tmp"; then _tmp=.$_tmp; fi _tmp=$v$_tmp _guile_candidates="guile-$_tmp guile$_tmp $_guile_candidates" done echo $_guile_candidates And the version with the fix is #!/bin/sh _guile_required_version=$1 _guile_candidates=guile _tmp= for v in `echo "$_guile_required_version" | tr . ' '`; do if test -n "$_tmp"; then _tmp=$_tmp.; fi _tmp=$_tmp$v _guile_candidates="guile-$_tmp guile$_tmp $_guile_candidates" done echo $_guile_candidates On Thu, Feb 23, 2017 at 10:43 AM, Andy Wingo wrote: > Hi Freja, > > Thanks for this bug report and the patch, and sorry for the delay :) > > On Mon 10 Oct 2016 11:45, Freja Nordsiek writes: > >> While trying to build a package that uses guile with autotools, I >> found a problem in the provided GUILE_PROGS macro. >> >> The macro searches for the executables guile, guild, guile-config, and >> guile-tools. The problem is that even if the macro is given the >> version, it only looks for guile, guild, etc. with no version suffix. > > Applied your patch with some small modifications; attached. Let me know > if it works for you! > > Andy > From 205f41d41b94f12670394ec526dddeaf1416d740 Mon Sep 17 00:00:00 2001 From: Freja Nordsiek Date: Tue, 14 Mar 2017 15:14:47 +0100 Subject: [PATCH] Fixed reversed version order bug in GUILE_PROGS Autoconf macro. --- meta/guile.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/guile.m4 b/meta/guile.m4 index 4a2e285..501a21c 100644 --- a/meta/guile.m4 +++ b/meta/guile.m4 @@ -234,8 +234,8 @@ AC_DEFUN([GUILE_PROGS], _guile_candidates=guile _tmp= for v in `echo "$_guile_required_version" | tr . ' '`; do -if test -n "$_tmp"; then _tmp=.$_tmp; fi -_tmp=$v$_tmp +if test -n "$_tmp"; then _tmp=$_tmp.; fi +_tmp=$_tmp$v _guile_candidates="guile-$_tmp guile$_tmp $_guile_candidates" done -- 2.9.3
bug#24657: Autoconf macro GUILE_PROGS only looks for guile without version suffix even if given version - patch included
On Tue 14 Mar 2017 15:25, Freja Nordsiek writes: > Found a bug in the modifications you made. Sorry for not catching this > before it got included into the Guile 2.1.8 release. Thank you! Applied. Note that in the gnu coding standards you need an entry in the commit log for every file you modify. Blah, I know, but that's how it is. Andy
bug#26058: utf16->string and utf32->string don't conform to R6RS
Andy Wingo writes: > On Mon 13 Mar 2017 19:10, taylanbayi...@gmail.com (Taylan Ulrich > "Bayırlı/Kammer") writes: > >> If I do binary I/O, the following situations are possible: >> >> 1. I'm guaranteed to get any possible bytes that happen to form a valid >>BOM at the start of the stream as-is in the returned bytevector; the >>binary I/O interface doesn't see such bytes as anything special, as >>it could simply be coincidence that the stream starts with such >>bytes. > > (1). But I thought this bug was about using a bytevector as a source > and then doing textual I/O on it, no? I have a feeling we're somehow talking past each other. :-) As far as I'm concerned, the bug is just that the procedures don't conform to the specification. It would of course be good if the behavior of these procedures was somehow in harmony with the behavior of I/O operations, but I don't see any issues arising from adopting the R6RS behavior of the procedures utf16->string and utf32->string. Do you? Taylan
bug#26058: utf16->string and utf32->string don't conform to R6RS
On Tue 14 Mar 2017 16:03, taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes: > Andy Wingo writes: > >> On Mon 13 Mar 2017 19:10, taylanbayi...@gmail.com (Taylan Ulrich >> "Bayırlı/Kammer") writes: >> >>> If I do binary I/O, the following situations are possible: >>> >>> 1. I'm guaranteed to get any possible bytes that happen to form a valid >>>BOM at the start of the stream as-is in the returned bytevector; the >>>binary I/O interface doesn't see such bytes as anything special, as >>>it could simply be coincidence that the stream starts with such >>>bytes. >> >> (1). But I thought this bug was about using a bytevector as a source >> and then doing textual I/O on it, no? > > I have a feeling we're somehow talking past each other. :-) As far as > I'm concerned, the bug is just that the procedures don't conform to the > specification. > > It would of course be good if the behavior of these procedures was > somehow in harmony with the behavior of I/O operations, but I don't see > any issues arising from adopting the R6RS behavior of the procedures > utf16->string and utf32->string. Do you? Adopting the behavior is more or less fine. If it can be done while relying on the existing behavior, that is better than something ad-hoc in a module. Andy
