[#61171] Re: [ruby-changes:33145] normal:r45224 (trunk): gc.c: fix build for testing w/o RGenGC — SASADA Koichi <ko1@...>
(2014/03/01 16:15), normal wrote:
3 messages
2014/03/01
[#61243] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — normalperson@...
Issue #9425 has been updated by Eric Wong.
4 messages
2014/03/03
[#61359] [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs — normalperson@...
Issue #9609 has been reported by Eric Wong.
5 messages
2014/03/07
[#61360] Re: [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs
— SASADA Koichi <ko1@...>
2014/03/07
(2014/03/07 19:09), [email protected] wrote:
[#61362] Re: [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs
— Eric Wong <normalperson@...>
2014/03/07
SASADA Koichi <[email protected]> wrote:
[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>
I'm unsure about this. I _hate_ the extra branches this adds;
13 messages
2014/03/12
[#61466] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/13
Hi Eric,
[#61471] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— Eric Wong <normalperson@...>
2014/03/13
SASADA Koichi <[email protected]> wrote:
[#61508] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/15
(2014/03/14 2:12), Eric Wong wrote:
[#61509] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— Eric Wong <normalperson@...>
2014/03/15
SASADA Koichi <[email protected]> wrote:
[#61510] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/15
(2014/03/15 17:34), Eric Wong wrote:
[#61452] [ruby-trunk - Feature #9632] [Open] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been reported by Eric Wong.
3 messages
2014/03/13
[#61496] [ruby-trunk - Feature #9638] [Open] [PATCH] limit IDs to 32-bits on 64-bit systems — normalperson@...
Issue #9638 has been reported by Eric Wong.
4 messages
2014/03/14
[#61568] hash function for global method cache — Eric Wong <normalperson@...>
I came upon this because I noticed existing st numtable worked poorly
7 messages
2014/03/17
[#61605] Re: hash function for global method cache
— SASADA Koichi <ko1@...>
2014/03/20
(2014/03/18 8:03), Eric Wong wrote:
[#61606] Re: hash function for global method cache
— Eric Wong <normalperson@...>
2014/03/20
SASADA Koichi <[email protected]> wrote:
[#61631] Re: hash function for global method cache
— =?KOI8-R?B?4NLJyiDzz8vPzM/X?= <funny.falcon@...>
2014/03/22
what's the profit from using binary tree in place of hash?
[#61632] Re: hash function for global method cache
— Eric Wong <normalperson@...>
2014/03/22
Юрий Соколов <[email protected]> wrote:
[#61687] [ruby-trunk - Bug #9606] Ocassional SIGSEGV inTestException#test_machine_stackoverflow on OpenBSD — normalperson@...
Issue #9606 has been updated by Eric Wong.
3 messages
2014/03/26
[#61760] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been updated by Eric Wong.
3 messages
2014/03/30
[ruby-core:61512] [ruby-trunk - Bug #9641] [Open] Digest libraries are built incorrectly due to ambiguous location of "extconf.h"
From:
ssouth@...
Date:
2014-03-15 12:45:43 UTC
List:
ruby-core #61512
Issue #9641 has been reported by Simon South. ---------------------------------------- Bug #9641: Digest libraries are built incorrectly due to ambiguous location of "extconf.h" https://bugs.ruby-lang.org/issues/9641 * Author: Simon South * Status: Open * Priority: Normal * Assignee: Nobuyoshi Nakada * Category: build * Target version: current: 2.2.0 * ruby -v: ruby 2.1.1p76 (2014-02-24 revision 45161) [i686-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- This is essentially the same issue as bug #3231, "Digest Does Not Build", which has reappeared for me on CentOS 6.5 using gcc 4.4.7. The attached patch changes the generated Makefiles so they explicitly specify the location of `extconf.h` as each module's own source-code folder. This removes the ambiguity at compile time of which copy of the file should be included, the module's or its parent's, and allows the digest classes to build correctly regardless of the how the compiler prioritizes the folders in its search path. It causes no additional test failures (on my system, at least) so I believe this change is safe. --- Here's the background: Building the latest version of Ruby, either 2.1.1p76 or the head revision in Subversion, on CentOS 6.5 (x86; gcc 4.4.7) with OpenSSL headers installed succeeds but the digest classes are unusable, producing error messages at runtime like ~~~ /usr/local/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:55:in `require': /usr/local/lib/ruby/2.2.0/i686-linux/digest/md5.so: undefined symbol: rb_Digest_MD5_Init - /usr/local/lib/ruby/2.2.0/i686-linux/digest/md5.so (LoadError) from /usr/local/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:55:in `require' from test-digest-classes.rb:1:in `<main>' ~~~ The reason is modules under `ext/digest` rely on generated `extconf.h` files to indicate OpenSSL headers are available. However, at compile time files with this name are available in the module's own directory *and* the parent's, both of which are in the compiler's search path (as other header files in the parent directory are needed). For whatever reason the compiler is insisting on using the `extconf.h` in the parent directory which causes each module to be misconfigured. The result is that Ruby's own digest-algorithm implementations are not built, as the build system correctly identifies them as unnecessary, but due to the `extconf.h` collision the source code assumes they *are* in use and therefore prepends "`rb_Digest_`" to several function names. These become unresolved symbols when the system attempts to load the library. The key to the solution is that if `extconf.h` in a module's parent folder is temporarily renamed, the module will build fine and be usable. There does not appear to be any standard way of specifying to the compiler which copy it ought to use without specifying the file's full path, which is what this patch accomplishes. ---Files-------------------------------- specify-extconf-h-location.patch (415 Bytes) -- http://bugs.ruby-lang.org/