[PATCH] Fixing srfi-18.test when building on OS X with clang

[PATCH] Fixing srfi-18.test when building on OS X with clang

[Chris K. Jester-Young]

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

Hi there,

I've recently been poking around the srfi-18.test failure that occurs
when building on OS X with the Xcode-provided clang. (Tested on OS X
10.10 Yosemite with Xcode 6.1.) It seems other people have experienced
the same problem on older versions, so it's not unique to this version:
http://lists.gnu.org/archive/html/guile-devel/2014-04/msg00003.html

Therefore, I've posted a patch in hopes that other OS X users could
test it out and see if it fixes things for them. Please let me know of
any improvements to the patch, too. :-)

The basic purpose of the patch is to disable thread-local storage when
building on OS X. This is probably clang-specific, but I don't have
enough autotools-fu to check for that. In any case, when using TLS, the
value of (current-thread) is not always correctly maintained, which
then causes srfi-18.test to fail.

Many thanks,
Chris.

P.S. Note that I manually build all the dependent packages, each at the
latest current version. I do not use Homebrew or anything similar, and
I always run "make check" and ensure that each package is green before
installing. Here are the actual versions I presently have installed:

+ autoconf-2.69
+ automake-1.14
+ bdwgc-7.4.2
+ gettext-0.19.3
+ gmp-6.0.0a
+ libatomic_ops-7.4.2
+ libffi-3.2.1
+ libtool-2.4.3
+ libunistring-0.9.4
+ pkg-config-0.28
+ readline-6.3

[-- Attachment #2: 0001-Do-not-use-thread-local-storage-on-OS-X.patch --]
[-- Type: text/x-diff, Size: 1439 bytes --]

From 18bc7bd726adb6c820bdc008c8e8fe091deb0313 Mon Sep 17 00:00:00 2001
From: Chris Jester-Young <cky944@gmail.com>
Date: Sun, 30 Nov 2014 02:10:51 -0500
Subject: [PATCH] Do not use thread-local storage on OS X.

* acinclude.m4 (GUILE_THREAD_LOCAL_STORAGE): Do not use thread-local
  storage on OS X. This causes (current-thread) to return the wrong
  value (tested under clang as bundled with Xcode 6.1), which causes
  srfi-18.test to fail.
---
 acinclude.m4 | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/acinclude.m4 b/acinclude.m4
index 8ef6e99..8eba3e1 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -380,8 +380,13 @@ AC_DEFUN([GUILE_THREAD_LOCAL_STORAGE], [
      dnl On `x86_64-unknown-freebsd8.0', thread-local storage appears to
      dnl be reclaimed at the wrong time, leading to a segfault when
      dnl running `threads.test'.  So disable it.
+     dnl
+     dnl On `x86_64-apple-darwin14.0.0', thread-local storage appears to
+     dnl return the wrong value for `scm_i_current_thread', resulting in
+     dnl (current-thread) returning the wrong value. This then causes
+     dnl `srfi-18.test' to fail.
      case "$enable_shared--$host_os" in
-       [yes--netbsd[0-5].[0-9]*|yes--solaris2.8|yes--freebsd[0-8]*])
+       [yes--netbsd[0-5].[0-9]*|yes--solaris2.8|yes--freebsd[0-8]*|yes--darwin*])
          ac_cv_have_thread_storage_class="no"
          ;;
        *)
-- 
1.9.3 (Apple Git-50)

Re: [PATCH] Fixing srfi-18.test when building on OS X with clang

[Ludovic Courtès]

"Chris K. Jester-Young" <cky944@gmail.com> skribis:

> The basic purpose of the patch is to disable thread-local storage when
> building on OS X. This is probably clang-specific, but I don't have
> enough autotools-fu to check for that. In any case, when using TLS, the
> value of (current-thread) is not always correctly maintained, which
> then causes srfi-18.test to fail.

I could try to come up with an Autoconf test for ‘__thread’, but what’s
the exact problem?  Is it that TLS in general doesn’t work (that sounds
unlikely)?  Or is it that TLS is inaccessible from a pthread_atexit
handler or something like that?

Thanks,
Ludo’.