llvm / clang and thread_local storage problems

[Jeremy Huddleston Sequoia]

That's not really a reduced test case.  It would be helpful if we could get a reduced test case of the problem that doesn't involve having to debug the entire guile application.  An ideal test case would be a small C or C++ file without external dependencies that showcased the issue.

--Jeremy

> On Oct 20, 2016, at 10:20 AM, Jack Howarth <howarth.at.macports at gmail.com> wrote:
> 
> On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
> <jeremyhu at apple.com> wrote:
>> 
>>> On Oct 9, 2016, at 09:47, Jack Howarth <howarth.at.macports at gmail.com> wrote:
>>> 
>>> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>>> <jeremyhu at apple.com> wrote:
>>>> thread_local support was added in OS X 10.9 (along with __cxa_thread_atexit being added to Libc as part of that support).  As long as your minimum deployment target is 10.9, you should be fine.  The issue is that you're on 10.6, so you don't have __cxa_thread_atexit.
>>>> 
>>>> There is active conversation right now about adding a fallback implementation of __cxa_thread_atexit directly into libcxxabi.  See https://reviews.llvm.org/D21803 as that might be quite useful for your needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll get it in.
>>> 
>>> On the topic of thread local support, the failures in the guile 2.0.x
>>> test suite should be looked at...
>>> 
>>> https://trac.macports.org/ticket/52556
>>> 
>>> to determine if Apple's thread-local-storage implementation is buggy
>>> as upstream guile claims.
>> 
>> Radar?
> 
> Jeremy,
>      I finally puzzled out how to run the offending test case in
> guile by itself. This can be done using the current MacPorts guile
> 2.0.13 using...
> 
> 
> 1) Installl MacPorts and then execute "sudo port -d install guile" in
> a Terminal window to install the dependencies required for guile as
> well as guile
> 2) In a terminal window, execute 'sudo port -d build guile' to rebuild
> guile retaining the build directory.
> 3) change directory into the MacPorts build directory for guile
> 2.0.13. In my case this was with....
> 
> cd /opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite
> 
> 5) change to sudo because MacPorts work directories are owned by root
> 
> sudo csh
> 
> 4) set the required environmental variables for the guile-test test
> harness script...
> 
> setenv GUILE_LOAD_PATH
> /opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite
> setenv TEST_SUITE_DIR
> /opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite/tests
> 
> 5) finally run the failing test case under the installed MacPort's guile...
> 
> /opt/local/bin/guile  -e main -s guile-test srfi-18.test
> 
> Running srfi-18.test
> FAIL: srfi-18.test: thread-terminate!: termination destroys non-started thread
> FAIL: srfi-18.test: thread-terminate!: termination destroys started thread
> 
> Totals for this test run:
> passes:                 59
> failures:               2
> unexpected passes:      0
> expected failures:      0
> unresolved test cases:  0
> untested test cases:    0
> unsupported test cases: 0
> errors:                 0
> 
> I've added those details to radar://28688091 "guile 2.0.12 exposes
> potential thread-local-storage bug on Mac OS X".
>             Jack
> ps The problem was that the comments in the guile-test test harness,
> for running the tests individually, mentioned the need to set
> TEST_SUITE_DIR but failed to discuss the need to set GUILE_LOAD_PATH
> as well.
> 
> 
>> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev