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.macpo...@gmail.com> > wrote: > > On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia > <jerem...@apple.com> wrote: >> >>> On Oct 9, 2016, at 09:47, Jack Howarth <howarth.at.macpo...@gmail.com> >>> wrote: >>> >>> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia >>> <jerem...@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@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
