* boehm-gc troubles with 2.0.10 on NetBSD/i386 @ 2014-04-11 13:14 Greg Troxel 2014-04-11 17:21 ` Mark H Weaver 0 siblings, 1 reply; 15+ messages in thread From: Greg Troxel @ 2014-04-11 13:14 UTC (permalink / raw) To: guile-devel [-- Attachment #1: Type: text/plain, Size: 1886 bytes --] I've been a guile user erratically for a long time, and maintain the entry for guile in pkgsrc. Currently that's at 1.8.8 and it works fine. There's a draft package for guile 2. boehm-gc in pkgsrc on NetBSD is built without threads, and I have --disable-threads passed to guile's configure. The build goes ok until trying to run guild. Just starting it without args leads to: /usr/pkgsrc/wip/guile2/work/guile-2.0.10/libguile > ../meta/uninstalled-env ../meta/guild 0xbbbe12d4 is not a GC visible pointer location GC_is_visible test failed Abort trap (core dumped) Trying with gdb: Starting program: /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.10/libguile/.libs/guile Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 1] 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 (gdb) bt #0 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 #1 0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1 #2 0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1 #3 0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1 #4 0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29 #5 0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29 #6 0xbbb670bc in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29 #7 0xbbb672d7 in with_guile_and_parent () from .libs/libguile-2.0.so.29 #8 0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1 #9 0xbbb674b9 in scm_with_guile () from .libs/libguile-2.0.so.29 #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29 #11 0x08048ce9 in main () When I run the included tests on boehm-gc 7.2e, they all past. So I wonder if you think this is a boehm-gc issue, or something odd that guile is doing to boehm-gc. Any hints would be appreciated. [-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.10 on NetBSD/i386 2014-04-11 13:14 boehm-gc troubles with 2.0.10 on NetBSD/i386 Greg Troxel @ 2014-04-11 17:21 ` Mark H Weaver 2014-04-11 18:14 ` Greg Troxel 2014-04-12 10:15 ` Ludovic Courtès 0 siblings, 2 replies; 15+ messages in thread From: Mark H Weaver @ 2014-04-11 17:21 UTC (permalink / raw) To: Greg Troxel; +Cc: guile-devel Hi Greg, Greg Troxel <gdt@ir.bbn.com> writes: > There's a draft package for guile 2. boehm-gc in pkgsrc on NetBSD is > built without threads, and I have --disable-threads passed to guile's > configure. As documented in our README and the output of ./configure --help, "--without-threads" is the option you should be using. To be honest, I'm not sure what "--disable-threads" will do, if anything. It's possible that gnulib is somehow enabling that option to be accepted without an error. Also, please don't use Guile 2.0.10. It was a brown-paper-bag release. Please use Guile 2.0.11, which was released 3 days after 2.0.10. > The build goes ok until trying to run guild. Just starting it without > args leads to: > > /usr/pkgsrc/wip/guile2/work/guile-2.0.10/libguile > ../meta/uninstalled-env ../meta/guild > 0xbbbe12d4 is not a GC visible pointer location > GC_is_visible test failed > Abort trap (core dumped) The relevant code is in gc.c line 632, which verifies that the GC can see the static variable 'scm_protects' defined in the same file. If it can't, that indicates a serious problem with the garbage collector. Before I investigate this any further, can you try with Guile 2.0.11 and passing "--without-threads" to ./configure? Regards, Mark > Trying with gdb: > > Starting program: /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.10/libguile/.libs/guile > > Program received signal SIGSEGV, Segmentation fault. > [Switching to LWP 1] > 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 > (gdb) bt > #0 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 > #1 0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1 > #2 0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1 > #3 0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1 > #4 0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29 > #5 0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29 > #6 0xbbb670bc in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29 > #7 0xbbb672d7 in with_guile_and_parent () from .libs/libguile-2.0.so.29 > #8 0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1 > #9 0xbbb674b9 in scm_with_guile () from .libs/libguile-2.0.so.29 > #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29 > #11 0x08048ce9 in main () > > When I run the included tests on boehm-gc 7.2e, they all past. > > > So I wonder if you think this is a boehm-gc issue, or something odd that > guile is doing to boehm-gc. Any hints would be appreciated. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.10 on NetBSD/i386 2014-04-11 17:21 ` Mark H Weaver @ 2014-04-11 18:14 ` Greg Troxel 2014-04-11 19:09 ` Mark H Weaver 2014-04-12 10:16 ` boehm-gc troubles with 2.0.10 " Ludovic Courtès 2014-04-12 10:15 ` Ludovic Courtès 1 sibling, 2 replies; 15+ messages in thread From: Greg Troxel @ 2014-04-11 18:14 UTC (permalink / raw) To: Mark H Weaver; +Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 4440 bytes --] Mark H Weaver <mhw@netris.org> writes: > As documented in our README and the output of ./configure --help, > "--without-threads" is the option you should be using. To be honest, > I'm not sure what "--disable-threads" will do, if anything. It's > possible that gnulib is somehow enabling that option to be accepted > without an error. Thanks for looking at my issue. Sorry, I typed that from memory. It was --with-threads=no and I changed it to --without-threads. My configure output shows: checking what kind of threads to support... null-threads > Also, please don't use Guile 2.0.10. It was a brown-paper-bag release. > Please use Guile 2.0.11, which was released 3 days after 2.0.10. OK; I've updated the package to 2.0.11. I now remember noticing that. >> The build goes ok until trying to run guild. Just starting it without >> args leads to: >> >> /usr/pkgsrc/wip/guile2/work/guile-2.0.10/libguile > ../meta/uninstalled-env ../meta/guild >> 0xbbbe12d4 is not a GC visible pointer location >> GC_is_visible test failed >> Abort trap (core dumped) > > The relevant code is in gc.c line 632, which verifies that the GC can > see the static variable 'scm_protects' defined in the same file. If it > can't, that indicates a serious problem with the garbage collector. > > Before I investigate this any further, can you try with Guile 2.0.11 and > passing "--without-threads" to ./configure? After fixing the --disable-threads and updating to 2.0.11, I get the following. I'll ask pkgsrc/netbsd people about libgc, since that seems to be the issue. /usr/pkgsrc/wip/guile2/work/guile-2.0.11/libguile > LD_LIBRARY_PATH=.libs gdb .libs/guile GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486--netbsdelf". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.11/libguile/.libs/guile...(no debugging symbols found)...done. (gdb) run Starting program: /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.11/libguile/.libs/guile Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 1] 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 (gdb) bt #0 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 #1 0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1 #2 0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1 #3 0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1 #4 0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29 #5 0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29 #6 0xbbb6712c in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29 #7 0xbbb67347 in with_guile_and_parent () from .libs/libguile-2.0.so.29 #8 0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1 #9 0xbbb67529 in scm_with_guile () from .libs/libguile-2.0.so.29 #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29 #11 0x08048ce9 in main () I realize this packaging control file is a foreign language, but here's how it looks: # $NetBSD$ # DISTNAME= guile-2.0.11 CATEGORIES= lang MASTER_SITES= ftp://ftp.gnu.org/gnu/guile/ MAINTAINER= root@zta.lk HOMEPAGE= ftp://ftp.gnu.org/gnu/guile/ COMMENT= Official extension language for the GNU operating system LICENSE= gnu-gpl-v3 GNU_CONFIGURE= yes USE_TOOLS+= pkg-config PKGCONFIG_OVERRIDE+= meta/guile-2.0.pc.in CONFIGURE_ARGS+= --without-threads #.include "../../mk/pthread.buildlink3.mk" # These are in the order given in guile's README. .include "../../devel/gmp/buildlink3.mk" .include "../../converters/libiconv/buildlink3.mk" .include "../../devel/gettext-lib/buildlink3.mk" .include "../../devel/libltdl/buildlink3.mk" .include "../../textproc/libunistring/buildlink3.mk" .include "../../devel/boehm-gc/buildlink3.mk" .include "../../devel/libffi/buildlink3.mk" .include "../../mk/bsd.pkg.mk" So really guile is building pretty close to natively. [-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.10 on NetBSD/i386 2014-04-11 18:14 ` Greg Troxel @ 2014-04-11 19:09 ` Mark H Weaver 2014-04-11 19:39 ` Greg Troxel 2014-04-12 10:16 ` boehm-gc troubles with 2.0.10 " Ludovic Courtès 1 sibling, 1 reply; 15+ messages in thread From: Mark H Weaver @ 2014-04-11 19:09 UTC (permalink / raw) To: Greg Troxel; +Cc: guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > After fixing the --disable-threads and updating to 2.0.11, I get the > following. I'll ask pkgsrc/netbsd people about libgc, since that seems > to be the issue. > > /usr/pkgsrc/wip/guile2/work/guile-2.0.11/libguile > LD_LIBRARY_PATH=.libs gdb .libs/guile > GNU gdb (GDB) 7.3.1 > Copyright (C) 2011 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486--netbsdelf". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from > /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.11/libguile/.libs/guile...(no > debugging symbols found)...done. > (gdb) run > Starting program: /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.11/libguile/.libs/guile > > Program received signal SIGSEGV, Segmentation fault. > [Switching to LWP 1] > 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 > (gdb) bt > #0 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 > #1 0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1 > #2 0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1 > #3 0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1 > #4 0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29 > #5 0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29 > #6 0xbbb6712c in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29 > #7 0xbbb67347 in with_guile_and_parent () from .libs/libguile-2.0.so.29 > #8 0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1 > #9 0xbbb67529 in scm_with_guile () from .libs/libguile-2.0.so.29 > #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29 > #11 0x08048ce9 in main () My guess is that this SIGSEGV is probably intentional, perhaps the method used by GC on NetBSD to determine the bounds of the stack or some other data area. I would try continuing and seeing what happens next. GC may also use some other signals for its own purposes. > I realize this packaging control file is a foreign language, but here's how it looks: > > # $NetBSD$ > # > > DISTNAME= guile-2.0.11 > CATEGORIES= lang > MASTER_SITES= ftp://ftp.gnu.org/gnu/guile/ > > MAINTAINER= root@zta.lk > HOMEPAGE= ftp://ftp.gnu.org/gnu/guile/ > COMMENT= Official extension language for the GNU operating system > LICENSE= gnu-gpl-v3 I think this license field is incorrect. Guile's license is the GNU _Lesser_ General Public License v3-or-later. Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.10 on NetBSD/i386 2014-04-11 19:09 ` Mark H Weaver @ 2014-04-11 19:39 ` Greg Troxel 2014-04-11 21:54 ` Mark H Weaver 0 siblings, 1 reply; 15+ messages in thread From: Greg Troxel @ 2014-04-11 19:39 UTC (permalink / raw) To: Mark H Weaver; +Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 1665 bytes --] Mark H Weaver <mhw@netris.org> writes: >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to LWP 1] >> 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 >> (gdb) bt >> #0 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 >> #1 0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1 >> #2 0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1 >> #3 0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1 >> #4 0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29 >> #5 0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29 >> #6 0xbbb6712c in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29 >> #7 0xbbb67347 in with_guile_and_parent () from .libs/libguile-2.0.so.29 >> #8 0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1 >> #9 0xbbb67529 in scm_with_guile () from .libs/libguile-2.0.so.29 >> #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29 >> #11 0x08048ce9 in main () > > My guess is that this SIGSEGV is probably intentional, perhaps the > method used by GC on NetBSD to determine the bounds of the stack or some > other data area. I would try continuing and seeing what happens next. > GC may also use some other signals for its own purposes. continuing leads to the program exiting. I should build libgc with debugging... >> LICENSE= gnu-gpl-v3 > > I think this license field is incorrect. Guile's license is the GNU > _Lesser_ General Public License v3-or-later. Is everything that is installed under LGPL, even readline? (But even if so, that should say "gnu-gpl-v3 AND gnu-lgpl-v3".) [-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.10 on NetBSD/i386 2014-04-11 19:39 ` Greg Troxel @ 2014-04-11 21:54 ` Mark H Weaver 2014-04-22 13:01 ` boehm-gc troubles with 2.0.11 " Greg Troxel 0 siblings, 1 reply; 15+ messages in thread From: Mark H Weaver @ 2014-04-11 21:54 UTC (permalink / raw) To: Greg Troxel; +Cc: guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > Mark H Weaver <mhw@netris.org> writes: > >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to LWP 1] >>> 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 >>> (gdb) bt >>> #0 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 >>> #1 0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1 >>> #2 0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1 >>> #3 0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1 >>> #4 0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29 >>> #5 0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29 >>> #6 0xbbb6712c in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29 >>> #7 0xbbb67347 in with_guile_and_parent () from .libs/libguile-2.0.so.29 >>> #8 0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1 >>> #9 0xbbb67529 in scm_with_guile () from .libs/libguile-2.0.so.29 >>> #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29 >>> #11 0x08048ce9 in main () >> >> My guess is that this SIGSEGV is probably intentional, perhaps the >> method used by GC on NetBSD to determine the bounds of the stack or some >> other data area. I would try continuing and seeing what happens next. >> GC may also use some other signals for its own purposes. > > continuing leads to the program exiting. I should build libgc with > debugging... In an earlier message, you wrote that guild prints the following when run normally: > /usr/pkgsrc/wip/guile2/work/guile-2.0.10/libguile > ../meta/uninstalled-env ../meta/guild > 0xbbbe12d4 is not a GC visible pointer location > GC_is_visible test failed > Abort trap (core dumped) Does this not happen when running it within GDB? It would be good to try building with -g and -Og or -O0, and perhaps also installing a more recent version of GDB. While helping someone working on getting Guile 2 into FreeBSD ports, I learned that FreeBSD includes a very old version of GDB, presumably to avoid the GNU GPLv3. We also learned that recent versions of GDB show function arguments in the backtrace whereas the GDB included in FreeBSD apparently doesn't. Perhaps the situation is similar on NetBSD. >>> LICENSE= gnu-gpl-v3 >> >> I think this license field is incorrect. Guile's license is the GNU >> _Lesser_ General Public License v3-or-later. > > Is everything that is installed under LGPL, even readline? > (But even if so, that should say "gnu-gpl-v3 AND gnu-lgpl-v3".) The Guile distribution includes an optional 'libguilereadline' library, which links with libreadline and is covered by GNU GPL v3-or-later. It is not used unless explicitly loaded by the user. Guile itself is covered by GNU LGPL v3-or-later. Regards, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.11 on NetBSD/i386 2014-04-11 21:54 ` Mark H Weaver @ 2014-04-22 13:01 ` Greg Troxel 2014-04-22 14:39 ` Taylan Ulrich Bayirli/Kammer ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Greg Troxel @ 2014-04-22 13:01 UTC (permalink / raw) To: Mark H Weaver; +Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 953 bytes --] A partial update: I am using 2.0.11 now. After updating to libgc 7.4.0, I have the same problem with a similar stack trace. libgc is built without threads and passes it's "gmake check". I have the same problem with libgc 7.4.0 on netbsd-5/i386 (libgc passes gmake check on this combination also). On netbsd-5/i386, I tried to build libgc and guile with threads, but it failed to link with tls_get_addr. This is likely a known lack of support in netbsd-5 which AFAIK doesn't provide thread-local storage. I haven't yet compiled libgc and guile with debugging symbols and without optimization; I realize that's what I need to do to figure this out. I read a bit of the code to get started understanding the boot sequence. It seems there is detection of stack growth detection. I wonder if that's somehow going astray. I am curious if others are having success on other *BSD, and which versions and architectures. [-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.11 on NetBSD/i386 2014-04-22 13:01 ` boehm-gc troubles with 2.0.11 " Greg Troxel @ 2014-04-22 14:39 ` Taylan Ulrich Bayirli/Kammer 2014-04-22 16:14 ` Mark H Weaver 2014-09-20 6:16 ` In-Ho Yi 2 siblings, 0 replies; 15+ messages in thread From: Taylan Ulrich Bayirli/Kammer @ 2014-04-22 14:39 UTC (permalink / raw) To: Greg Troxel; +Cc: Mark H Weaver, guile-devel Greg Troxel <gdt@ir.bbn.com> writes: > I am curious if others are having success on other *BSD, and which > versions and architectures. 2.0.11 was fine on OpenBSD 5.3 amd64 AKA x86_64, with libgc 7.4. (Sadly I'm not on OpenBSD anymore so in case you have detailed questions I may not be able to answer them.) OS X 10.9 is also mostly fine, though with some issues. See relevant ML thread, "2.0.11 on OS X 10.9 / Xcode 5.1". Taylan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.11 on NetBSD/i386 2014-04-22 13:01 ` boehm-gc troubles with 2.0.11 " Greg Troxel 2014-04-22 14:39 ` Taylan Ulrich Bayirli/Kammer @ 2014-04-22 16:14 ` Mark H Weaver 2014-09-20 6:16 ` In-Ho Yi 2 siblings, 0 replies; 15+ messages in thread From: Mark H Weaver @ 2014-04-22 16:14 UTC (permalink / raw) To: Greg Troxel; +Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 580 bytes --] Greg Troxel <gdt@ir.bbn.com> writes: > I am curious if others are having success on other *BSD, and which > versions and architectures. zacts on #guile has done work on a guile 2.0.11 package for FreeBSD ports, and based on his reports it seems to work well. IIRC, he built it (and boehm-gc) with threads enabled (pthreads). There was just one notable issue: guile needs a patch (see attached) for clang 3.4 on 32-bit systems. I haven't yet pushed this to git because it needs to be made more portable. Anyway, I doubt it's related to the problem you're seeing. Mark [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Preliminary guile fix for clang 3.4 on 32-bit systems --] [-- Type: text/x-patch, Size: 1517 bytes --] diff --git a/libguile/foreign.c b/libguile/foreign.c index 01af900..59f5e72 100644 --- a/libguile/foreign.c +++ b/libguile/foreign.c @@ -814,7 +814,7 @@ SCM_DEFINE (scm_pointer_to_procedure, "pointer->procedure", 3, 0, 0, static const struct { - scm_t_uint64 dummy; /* ensure 8-byte alignment; perhaps there's a better way */ + SCM_ALIGNED (8) scm_t_uint64 dummy; /* alignment */ const scm_t_uint8 bytes[10 * (sizeof (struct scm_objcode) + 8 + sizeof (struct scm_objcode) + 32)]; } raw_bytecode = { @@ -867,7 +867,7 @@ make_objcode_trampoline (unsigned int nargs) static const struct { - scm_t_uint64 dummy; /* alignment */ + SCM_ALIGNED (8) scm_t_uint64 dummy; /* alignment */ scm_t_cell cells[10 * 2]; /* 10 double cells */ } objcode_cells = { 0, diff --git a/libguile/gsubr.c b/libguile/gsubr.c index b6f261f..38b7ce1 100644 --- a/libguile/gsubr.c +++ b/libguile/gsubr.c @@ -213,7 +213,7 @@ */ static const struct { - scm_t_uint64 dummy; /* ensure 8-byte alignment; perhaps there's a better way */ + SCM_ALIGNED (8) scm_t_uint64 dummy; /* alignment */ const scm_t_uint8 bytes[121 * (sizeof (struct scm_objcode) + 16 + sizeof (struct scm_objcode) + 32)]; } raw_bytecode = { @@ -317,7 +317,7 @@ static const struct static const struct { - scm_t_uint64 dummy; /* alignment */ + SCM_ALIGNED (8) scm_t_uint64 dummy; /* alignment */ scm_t_cell cells[121 * 2]; /* 11*11 double cells */ } objcode_cells = { 0, ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.11 on NetBSD/i386 2014-04-22 13:01 ` boehm-gc troubles with 2.0.11 " Greg Troxel 2014-04-22 14:39 ` Taylan Ulrich Bayirli/Kammer 2014-04-22 16:14 ` Mark H Weaver @ 2014-09-20 6:16 ` In-Ho Yi 2014-09-20 23:25 ` Mark H Weaver 2 siblings, 1 reply; 15+ messages in thread From: In-Ho Yi @ 2014-09-20 6:16 UTC (permalink / raw) To: Guile-devel I've continued execution after GC_find_limit_with_bound SIGSEGVs, and finally I hit this point Program received signal SIGSEGV, Segmentation fault. 0x00007f7ff7721d84 in scm_variable_ref (var=0x0) at variable.c:93 93 SCM_VALIDATE_VARIABLE (1, var); (gdb) bt #0 0x00007f7ff7721d84 in scm_variable_ref (var=0x0) at variable.c:93 #1 0x00007f7ff771ff0a in scm_throw (key=0x0, args=0x658240) at throw.c:98 #2 0x00007f7ff77205ae in scm_ithrow (key=0x0, args=0x658240, no_return=1) at throw.c:435 #3 0x00007f7ff767cc7c in scm_error_scm (key=0x0, subr=0x644f80, message=0x644fa0, args=0x304, data=0x4) at error.c:94 #4 0x00007f7ff767cc2d in scm_error (key=0x0, subr=0x7f7ff778e162 "scm_hash_fn_create_handle_x", message=0x7f7ff778e17e "void hashtable", args=0x304, rest=0x4) at error.c:60 #5 0x00007f7ff767d20e in scm_misc_error (subr=0x7f7ff778e162 "scm_hash_fn_create_handle_x", message=0x7f7ff778e17e "void hashtable", args=0x304) at error.c:304 #6 0x00007f7ff76a08b2 in scm_hash_fn_create_handle_x (table=0x64cfe0, obj=0x644fc0, init=0x904, hash_fn=0x7f7ff771b60b <symbol_lookup_hash_fn>, assoc_fn=0x7f7ff771b634 <symbol_lookup_assoc_fn>, closure=0x0) at hashtab.c:691 #7 0x00007f7ff771b721 in intern_symbol (symbol=0x644fc0) at symbols.c:195 #8 0x00007f7ff771b7bf in scm_i_str2symbol (str=0x7f7ff79d9908) at symbols.c:218 #9 0x00007f7ff771b9cd in scm_string_to_symbol (string=0x7f7ff79d9908) at symbols.c:323 #10 0x00007f7ff7721fda in scm_init_variable () at ../libguile/variable.x:4 #11 0x00007f7ff76a7fa7 in scm_i_init_guile (base=0x7f7fffffdad0) at init.c:407 #12 0x00007f7ff771d143 in scm_i_init_thread_for_guile (base=0x7f7fffffdad0, parent=0x0) at threads.c:833 #13 0x00007f7ff771d24e in with_guile_and_parent (base=0x7f7fffffdad0, data=0x7f7fffffdb10) at threads.c:899 #14 0x00007f7ff721de1f in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1 #15 0x00007f7ff771d386 in scm_i_with_guile_and_parent (func=0x7f7ff76a7e1c <invoke_main_func>, data=0x7f7fffffdb80, parent=0x0) at threads.c:949 #16 0x00007f7ff771d3b2 in scm_with_guile (func=0x7f7ff76a7e1c <invoke_main_func>, data=0x7f7fffffdb80) at threads.c:955 #17 0x00007f7ff76a7dfd in scm_boot_guile (argc=1, argv=0x7f7fffffdc18, main_func=0x400fec <inner_main>, closure=0x0) at init.c:319 #18 0x0000000000401121 in main (argc=1, argv=0x7f7fffffdc18) at guile.c:108 where it finally fails. I'm trying guile2 2.0.11 built from pkgsrc wip with --without-threads configuration option on NetBSD/i386 6.1.4 -- View this message in context: http://gnu-guile.7481.n7.nabble.com/boehm-gc-troubles-with-2-0-10-on-NetBSD-i386-tp18473p19272.html Sent from the Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.11 on NetBSD/i386 2014-09-20 6:16 ` In-Ho Yi @ 2014-09-20 23:25 ` Mark H Weaver 0 siblings, 0 replies; 15+ messages in thread From: Mark H Weaver @ 2014-09-20 23:25 UTC (permalink / raw) To: In-Ho Yi; +Cc: Guile-devel In-Ho Yi <chajath@gmail.com> writes: > I've continued execution after GC_find_limit_with_bound SIGSEGVs, and > finally I hit this point > > Program received signal SIGSEGV, Segmentation fault. > 0x00007f7ff7721d84 in scm_variable_ref (var=0x0) at variable.c:93 > 93 SCM_VALIDATE_VARIABLE (1, var); First, can you verify that you have the following patch applied? http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=156119b0223cf14d335ebda84701a69b2ba95757 It was not in 2.0.11 and is needed for 32-bit clang builds. > I'm trying guile2 2.0.11 built from pkgsrc wip with --without-threads > configuration option on NetBSD/i386 6.1.4 Which version of bdw-gc? Thanks, Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.10 on NetBSD/i386 2014-04-11 18:14 ` Greg Troxel 2014-04-11 19:09 ` Mark H Weaver @ 2014-04-12 10:16 ` Ludovic Courtès 2014-04-12 17:06 ` Mark H Weaver 2014-04-12 23:56 ` Greg Troxel 1 sibling, 2 replies; 15+ messages in thread From: Ludovic Courtès @ 2014-04-12 10:16 UTC (permalink / raw) To: guile-devel Greg, does libgc’s own ‘make check’ pass on this platform? Ludo’. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.10 on NetBSD/i386 2014-04-12 10:16 ` boehm-gc troubles with 2.0.10 " Ludovic Courtès @ 2014-04-12 17:06 ` Mark H Weaver 2014-04-12 23:56 ` Greg Troxel 1 sibling, 0 replies; 15+ messages in thread From: Mark H Weaver @ 2014-04-12 17:06 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel ludo@gnu.org (Ludovic Courtès) writes: > Greg, does libgc’s own ‘make check’ pass on this platform? In the first message of this thread, Greg wrote: > When I run the included tests on boehm-gc 7.2e, they all past. Mark ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.10 on NetBSD/i386 2014-04-12 10:16 ` boehm-gc troubles with 2.0.10 " Ludovic Courtès 2014-04-12 17:06 ` Mark H Weaver @ 2014-04-12 23:56 ` Greg Troxel 1 sibling, 0 replies; 15+ messages in thread From: Greg Troxel @ 2014-04-12 23:56 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 10920 bytes --] I am using gc-7.2e, which is what pkgsrc has, and which http://www.hboehm.info/gc/ indicates is the latest stable version. This is with gcc 4.5.3 on i386. ludo@gnu.org (Ludovic Courtès) writes: > Greg, does libgc’s own ‘make check’ pass on this platform? Yes. libgc seems to have multiple tests. pkgsrc has the following, and it runs fine: do-test: cd ${WRKSRC} && \ ${RM} -f gctest && ${MAKE_PROGRAM} gctest && ./gctest && \ ${RM} -f test_cpp && ${MAKE_PROGRAM} test_cpp && ./test_cpp 10 also, cding into the build directory after the package is built and "gmake check" passes. gory details in case it matters, make test (above taret) and then check: ---------------------------------------- => Bootstrap dependency digest>=20010302: found digest-20121220 WARNING: [license.mk] Every package should define a LICENSE. ===> Testing for boehm-gc-7.2e cd /u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2 && /bin/rm -f gctest && /usr/pkg/bin/gmake gctest && ./gctest && /bin/rm -f test_cpp && /usr/pkg/bin/gmake test_cpp && ./test_cpp 10 gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT test.o -MD -MP -MF .deps/test.Tpo -c -o test.o `test -f 'tests/test.c' || echo './'`tests/test.c mv -f .deps/test.Tpo .deps/test.Po /bin/sh ./libtool --tag=CC --mode=link gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o gctest test.o ./libgc.la libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/gctest test.o -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib Completed 1 tests Allocated 747393 collectable objects Allocated 202 uncollectable objects Allocated 1250000 atomic objects Allocated 21760 stubborn objects Finalized 2206/2206 objects - finalization is probably ok Total number of bytes allocated is 90678890 Final heap size is 4927488 bytes Collector appears to work c++ -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -O2 -MT test_cpp.o -MD -MP -MF .deps/test_cpp.Tpo -c -o test_cpp.o `test -f 'tests/test_cpp.cc' || echo './'`tests/test_cpp.cc mv -f .deps/test_cpp.Tpo .deps/test_cpp.Po /bin/sh ./libtool --tag=CXX --mode=link c++ -fexceptions -O2 -Wl,-R/usr/pkg/lib -o test_cpp test_cpp.o libgccpp.la ./libgc.la libtool: link: c++ -fexceptions -O2 -Wl,-R/usr/pkg/lib -o .libs/test_cpp test_cpp.o -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2/.libs -L./.libs -lgccpp -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -lgc -Wl,-rpath,/usr/pkg/lib Starting iteration 1 Starting iteration 2 Starting iteration 3 Starting iteration 4 Starting iteration 5 Starting iteration 6 Starting iteration 7 Starting iteration 8 Starting iteration 9 Starting iteration 10 The test appears to have succeeded. ---------------------------------------- gmake[1]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' gmake libstaticrootslib.la gctest leaktest middletest smashtest hugetest realloc_test staticrootstest test_cpp gmake[2]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT staticrootslib.lo -MD -MP -MF .deps/staticrootslib.Tpo -c -o staticrootslib.lo `test -f 'tests/staticrootslib.c' || echo './'`tests/staticrootslib.c libtool: compile: gcc -DHAVE_CONFIG_H -I./include -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT staticrootslib.lo -MD -MP -MF .deps/staticrootslib.Tpo -c tests/staticrootslib.c -fPIC -DPIC -o .libs/staticrootslib.o libtool: compile: gcc -DHAVE_CONFIG_H -I./include -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT staticrootslib.lo -MD -MP -MF .deps/staticrootslib.Tpo -c tests/staticrootslib.c -o staticrootslib.o >/dev/null 2>&1 mv -f .deps/staticrootslib.Tpo .deps/staticrootslib.Plo /bin/sh ./libtool --tag=CC --mode=link gcc -fexceptions -O2 -fno-strict-aliasing -version-info 1:3:0 -no-undefined -rpath /nowhere -Wl,-R/usr/pkg/lib -o libstaticrootslib.la staticrootslib.lo ./libgc.la libtool: link: gcc -shared -fPIC -DPIC .libs/staticrootslib.o -Wl,-rpath,/usr/pkgsrc/devel/boehm-gc/work/gc-7.2/.libs -Wl,-rpath,/usr/pkg/lib -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -O2 -Wl,-R/usr/pkg/lib -Wl,-soname -Wl,libstaticrootslib.so.1 -o .libs/libstaticrootslib.so.1.0.3 libtool: link: (cd ".libs" && rm -f "libstaticrootslib.so.1" && ln -s "libstaticrootslib.so.1.0.3" "libstaticrootslib.so.1") libtool: link: (cd ".libs" && rm -f "libstaticrootslib.so" && ln -s "libstaticrootslib.so.1.0.3" "libstaticrootslib.so") libtool: link: ar cru .libs/libstaticrootslib.a staticrootslib.o libtool: link: ranlib .libs/libstaticrootslib.a libtool: link: ( cd ".libs" && rm -f "libstaticrootslib.la" && ln -s "../libstaticrootslib.la" "libstaticrootslib.la" ) gmake[2]: 'gctest' is up to date. gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT leak_test.o -MD -MP -MF .deps/leak_test.Tpo -c -o leak_test.o `test -f 'tests/leak_test.c' || echo './'`tests/leak_test.c mv -f .deps/leak_test.Tpo .deps/leak_test.Po /bin/sh ./libtool --tag=CC --mode=link gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o leaktest leak_test.o ./libgc.la libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/leaktest leak_test.o -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT middle.o -MD -MP -MF .deps/middle.Tpo -c -o middle.o `test -f 'tests/middle.c' || echo './'`tests/middle.c mv -f .deps/middle.Tpo .deps/middle.Po /bin/sh ./libtool --tag=CC --mode=link gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o middletest middle.o ./libgc.la libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/middletest middle.o -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT smash_test.o -MD -MP -MF .deps/smash_test.Tpo -c -o smash_test.o `test -f 'tests/smash_test.c' || echo './'`tests/smash_test.c mv -f .deps/smash_test.Tpo .deps/smash_test.Po /bin/sh ./libtool --tag=CC --mode=link gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o smashtest smash_test.o ./libgc.la libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/smashtest smash_test.o -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT huge_test.o -MD -MP -MF .deps/huge_test.Tpo -c -o huge_test.o `test -f 'tests/huge_test.c' || echo './'`tests/huge_test.c mv -f .deps/huge_test.Tpo .deps/huge_test.Po /bin/sh ./libtool --tag=CC --mode=link gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o hugetest huge_test.o ./libgc.la libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/hugetest huge_test.o -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT realloc_test.o -MD -MP -MF .deps/realloc_test.Tpo -c -o realloc_test.o `test -f 'tests/realloc_test.c' || echo './'`tests/realloc_test.c mv -f .deps/realloc_test.Tpo .deps/realloc_test.Po /bin/sh ./libtool --tag=CC --mode=link gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o realloc_test realloc_test.o ./libgc.la libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/realloc_test realloc_test.o -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib gcc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT staticrootstest.o -MD -MP -MF .deps/staticrootstest.Tpo -c -o staticrootstest.o `test -f 'tests/staticrootstest.c' || echo './'`tests/staticrootstest.c mv -f .deps/staticrootstest.Tpo .deps/staticrootstest.Po /bin/sh ./libtool --tag=CC --mode=link gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o staticrootstest staticrootstest.o ./libgc.la libstaticrootslib.la libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/staticrootstest staticrootstest.o -L/usr/pkgsrc/devel/boehm-gc/work/gc-7.2/.libs -L./.libs -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -lstaticrootslib -lgc -Wl,-rpath,/usr/pkg/lib -Wl,-rpath,/nowhere gmake[2]: 'test_cpp' is up to date. gmake[2]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' gmake check-TESTS gmake[2]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' gmake[3]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' PASS: gctest PASS: leaktest PASS: middletest PASS: smashtest PASS: hugetest PASS: realloc_test PASS: staticrootstest PASS: test_cpp gmake[4]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' gmake[5]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' gmake[5]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' gmake[4]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' ============================================================================ Testsuite summary for gc 7.2 ============================================================================ # TOTAL: 8 # PASS: 8 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ gmake[3]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' gmake[2]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' gmake[1]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2' ---------------------------------------- [-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: boehm-gc troubles with 2.0.10 on NetBSD/i386 2014-04-11 17:21 ` Mark H Weaver 2014-04-11 18:14 ` Greg Troxel @ 2014-04-12 10:15 ` Ludovic Courtès 1 sibling, 0 replies; 15+ messages in thread From: Ludovic Courtès @ 2014-04-12 10:15 UTC (permalink / raw) To: guile-devel Mark H Weaver <mhw@netris.org> skribis: > Greg Troxel <gdt@ir.bbn.com> writes: > >> There's a draft package for guile 2. boehm-gc in pkgsrc on NetBSD is >> built without threads, and I have --disable-threads passed to guile's >> configure. > > As documented in our README and the output of ./configure --help, > "--without-threads" is the option you should be using. To be honest, > I'm not sure what "--disable-threads" will do, if anything. It's > possible that gnulib is somehow enabling that option to be accepted > without an error. As for all unrecognized options, ./configure prints a warning and ignores it. Ludo’. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-09-20 23:25 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-04-11 13:14 boehm-gc troubles with 2.0.10 on NetBSD/i386 Greg Troxel 2014-04-11 17:21 ` Mark H Weaver 2014-04-11 18:14 ` Greg Troxel 2014-04-11 19:09 ` Mark H Weaver 2014-04-11 19:39 ` Greg Troxel 2014-04-11 21:54 ` Mark H Weaver 2014-04-22 13:01 ` boehm-gc troubles with 2.0.11 " Greg Troxel 2014-04-22 14:39 ` Taylan Ulrich Bayirli/Kammer 2014-04-22 16:14 ` Mark H Weaver 2014-09-20 6:16 ` In-Ho Yi 2014-09-20 23:25 ` Mark H Weaver 2014-04-12 10:16 ` boehm-gc troubles with 2.0.10 " Ludovic Courtès 2014-04-12 17:06 ` Mark H Weaver 2014-04-12 23:56 ` Greg Troxel 2014-04-12 10:15 ` Ludovic Courtès
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).