From unknown Mon Aug 18 04:05:39 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#19997 <19997@debbugs.gnu.org> To: bug#19997 <19997@debbugs.gnu.org> Subject: Status: Performance differences between Git sources and release tarballs? Reply-To: bug#19997 <19997@debbugs.gnu.org> Date: Mon, 18 Aug 2025 11:05:39 +0000 retitle 19997 Performance differences between Git sources and release tarba= lls? reassign 19997 grep submitter 19997 sur-behoffski severity 19997 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 03 22:21:59 2015 Received: (at submit) by debbugs.gnu.org; 4 Mar 2015 03:21:59 +0000 Received: from localhost ([127.0.0.1]:34394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YSzsk-0002KZ-Iu for submit@debbugs.gnu.org; Tue, 03 Mar 2015 22:21:59 -0500 Received: from eggs.gnu.org ([208.118.235.92]:59777) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YSzsh-0002KL-OQ for submit@debbugs.gnu.org; Tue, 03 Mar 2015 22:21:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSzsb-0005oH-EJ for submit@debbugs.gnu.org; Tue, 03 Mar 2015 22:21:50 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSzsb-0005oD-B0 for submit@debbugs.gnu.org; Tue, 03 Mar 2015 22:21:49 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSzsW-0002ox-Ms for bug-grep@gnu.org; Tue, 03 Mar 2015 22:21:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSzsS-0005mL-7u for bug-grep@gnu.org; Tue, 03 Mar 2015 22:21:44 -0500 Received: from ipmail04.adl6.internode.on.net ([150.101.137.141]:39957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSzsR-0005lu-SQ for bug-grep@gnu.org; Tue, 03 Mar 2015 22:21:40 -0500 Received: from ppp118-210-54-50.lns20.adl2.internode.on.net (HELO [192.168.178.20]) ([118.210.54.50]) by ipmail04.adl6.internode.on.net with ESMTP; 04 Mar 2015 13:51:33 +1030 Message-ID: <54F67A3C.80501@grouse.com.au> Date: Wed, 04 Mar 2015 13:51:32 +1030 From: sur-behoffski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "bug-grep@gnu.org" Subject: Performance differences between Git sources and release tarballs? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) G'day, I'm working on comparing the performance of my Boyer-Moore string search code in the hstbm[1] project, versus the equivalent code in GNU Grep (src/kwset.c). My hope is to expand the very narrow corpus of patterns and file data types that I've used to-date in my testing. The major risk in varying a tuned algorithm such as B-M is that pathological data, and/or important normal cases, may suffer a performance hit as a result of the variations. I'm trying to locate, or perhaps build, a corpus, together with a detailed performance profile, for the limited set of hardware that I have access to. Generalising the testing to other architectures, OSes and/or compiler toolchains is a further target. (I note that, in the recent past, others have suggested Project Gutenberg's text of the King James Version of the Bible as one possible member of such a test corpus.) I'm looking to use PAPI[2] in order to use hardware counters to help pick apart where CPU time is spent; but more on that when I have some sentient results to report. I decided to start by looking at why GNU Grep was significantly slower than hstbm when searching for a trivial pattern ("123") in /dev/null. I knew that one test (invoking the command 1000 times inside a timed shell script) that GNU Grep was roughly 20% slower. I found that "fgrep" -- more precisely, "grep -F", was a significant factor -- the grep pattern compilation was more expensive than the fgrep (src/kwsearch.c) compilation. NLS is another difference; hstbm does not call "bindtextdomain" or "textdomain"; but again, more on that another time. When starting to add instrumentation to GNU Grep (grep.c's main), I found that it was up to 300% slower, not the 20%ish that I'd measured previously. After vanishing down a number of rabbit-holes, some to do with GCC's architecture selection, I've found that the 2.21 tarball has high performance, whereas the Git head is much, much slower. (I use a source-based (Gentoo) Linux OS, so am able to dissect the stages of Gentoo's build steps... a little.) Looking at Grep's "configure --help" output, I see that "--enable-gcc-warnings" is an option, and, with some experimentation with invoking compilation in different environments, it seems that a slew of warning options is enabled in the development tree, that are not enabled in the release tarball. This is when I naively invoke ./configure without looking closely at all the possible configuration options. So, could you please give me some guidance as to why the release tarball would build so differently to the development (Git head) set of sources? Apologies in advance if there's some documentation that I overlooked. thanks, sur-behoffski (Brenton Hoff) Programmer, Grouse Software [1] http://savannah.nongnu.org/projects/hstbm [2] http://icl.cs.utk.edu/papi/ From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 04 02:18:33 2015 Received: (at 19997) by debbugs.gnu.org; 4 Mar 2015 07:18:33 +0000 Received: from localhost ([127.0.0.1]:34481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YT3Zh-00085s-4M for submit@debbugs.gnu.org; Wed, 04 Mar 2015 02:18:33 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:41686) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YT3Ze-00085f-TP for 19997@debbugs.gnu.org; Wed, 04 Mar 2015 02:18:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 69B67A6000E; Tue, 3 Mar 2015 23:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5F1Dl4XP4jG; Tue, 3 Mar 2015 23:18:24 -0800 (PST) Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 2502139E807B; Tue, 3 Mar 2015 23:18:24 -0800 (PST) Message-ID: <54F6B1BB.1080904@cs.ucla.edu> Date: Tue, 03 Mar 2015 23:18:19 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sur-behoffski , 19997@debbugs.gnu.org Subject: Re: bug#19997: Performance differences between Git sources and release tarballs? References: <54F67A3C.80501@grouse.com.au> In-Reply-To: <54F67A3C.80501@grouse.com.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19997 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) sur-behoffski wrote: > Looking at Grep's "configure --help" output, I see that > "--enable-gcc-warnings" is an option, and, with some experimentation with > invoking compilation in different environments, it seems that a slew of > warning options is enabled in the development tree, that are not enabled in > the release tarball. These shouldn't affect grep's runtime performance. I don't know why you're observing the performance you do. It could be that you're building 'grep' differently from the way Gentoo builds it. You might try building both grep 2.21 and grep master yourself, with the same build procedure both ways. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 10 02:00:36 2015 Received: (at 19997) by debbugs.gnu.org; 10 Mar 2015 06:00:36 +0000 Received: from localhost ([127.0.0.1]:41128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVDDX-0006oA-7m for submit@debbugs.gnu.org; Tue, 10 Mar 2015 02:00:35 -0400 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:26095) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVDDT-0006nv-KC for 19997@debbugs.gnu.org; Tue, 10 Mar 2015 02:00:33 -0400 Received: from ppp14-2-47-189.lns21.adl2.internode.on.net (HELO [192.168.178.20]) ([14.2.47.189]) by ipmail06.adl6.internode.on.net with ESMTP; 10 Mar 2015 16:29:28 +1030 Message-ID: <54FE883F.2040206@grouse.com.au> Date: Tue, 10 Mar 2015 16:29:27 +1030 From: sur-behoffski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: 19997@debbugs.gnu.org Subject: Re: bug#19997: Performance differences between Git sources and release tarballs? References: <54F67A3C.80501@grouse.com.au> <54F6B1BB.1080904@cs.ucla.edu> In-Reply-To: <54F6B1BB.1080904@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19997 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 03/04/15 17:48, Paul Eggert wrote: > sur-behoffski wrote: >> Looking at Grep's "configure --help" output, I see that >> "--enable-gcc-warnings" is an option, and, with some experimentation with >> invoking compilation in different environments, it seems that a slew of >> warning options is enabled in the development tree, that are not enabled in >> the release tarball. > > These shouldn't affect grep's runtime performance. > > I don't know why you're observing the performance you do. It could be that you're building 'grep' differently from the way Gentoo builds it. You might try building both grep 2.21 and grep master yourself, with the same build procedure both ways. > Okay, I think I have this issue sorted: Adding "-lpapi" to the link command results in more infrastructure effort before main() is called. If this change is factored out, then your comment looks to be correct: There should be no performance differences between Git/release tarball builds. The practical upshot is that PAPI's valuable for finding resource-heavy portions of code, but then has to be factored out, or possibly added in equally everywhere, when comparisons between programs are being made. For the factoring-out case, you have to adopt a dual-configuration stance: 1. PAPI involved in one-off runs, reporting results, highlighting places where resources are being used, and giving quick feedback for experimental code changes; plus 2. The program without PAPI (and also without any PAPI-associated intrusive monitoring changes whatsoever), built for multiple-repetition full-program timing runs. Here's a quick summary of results, followed by a more detailed look at program activity provided courtesy of "strace". The summary uses "repl", a Lua script that: - Uses "time" on a bash script that repeatedly invokes the program (e.g. 1000 "inner reps"); - Does this whole set multiple times (e.g. 50 "outer reps"); - Uses "nice -12" to reduce likely variation from other system activity; - Sleeps for a short while between outer reps to give other processes a chance, as otherwise "nice -12" might be unduly disruptive; - Crosses off a few of the fastest and slowest times as possibly being aberrations; - Sorts the remaining times; and - Reports the mean time, together with the lowest few (10) runs. cheers, sur-behoffski (Brenton Hoff) Programmer, Grouse Software ------------------------------------------------------------ Summary: "justmain.c" and -lpapi (yeah, I know "-O2 -pipe" doesn't do much; these are included as they are usual for my Gentoo system): $ cat justmain.c int main(void) { return 0; } $ gcc -O2 -pipe -o justmain justmain.c $ gcc -O2 -pipe -o justmain-papi justmain.c -lpapi $ repl 50/1000 ./justmain Cmd: "./justmain" [50/1000] Mean: 0.501; Lowest: 0.495 0.496 0.496 0.496 0.497 0.497 0.497 0.498 0.498 0.499 $ repl 50/1000 ./justmain-papi Cmd: "./justmain-papi" [50/1000] Mean: 0.988; Lowest: 0.964 0.965 0.965 0.968 0.970 0.973 0.974 0.975 0.977 0.978 ------------------------------------------------------------ Comparing the strace output for "justmain" and "justmain-papi" shows the extra effort needed for papi and other associated libraries: $ strace ./justmain execve("./justmain", ["./justmain"], [/* 37 vars */]) = 0 brk(0) = 0x1d40000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbae97eb000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=144976, ...}) = 0 mmap(NULL, 144976, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbae97c7000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300N\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1716576, ...}) = 0 mmap(NULL, 3828824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbae9225000 mprotect(0x7fbae93c3000, 2093056, PROT_NONE) = 0 mmap(0x7fbae95c2000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19d000) = 0x7fbae95c2000 mmap(0x7fbae95c8000, 15448, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbae95c8000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbae97c6000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbae97c5000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbae97c4000 arch_prctl(ARCH_SET_FS, 0x7fbae97c5700) = 0 mprotect(0x7fbae95c2000, 16384, PROT_READ) = 0 mprotect(0x600000, 4096, PROT_READ) = 0 mprotect(0x7fbae97ec000, 4096, PROT_READ) = 0 munmap(0x7fbae97c7000, 144976) = 0 exit_group(0) = ? +++ exited with 0 +++ $ strace ./justmain-papi execve("./justmain-papi", ["./justmain-papi"], [/* 37 vars */]) = 0 brk(0) = 0x2045000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2112cf4000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=144976, ...}) = 0 mmap(NULL, 144976, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2112cd0000 close(3) = 0 open("/usr/lib64/libpapi.so.5.4.0.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\353\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=356288, ...}) = 0 mmap(NULL, 2456816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f211287d000 mprotect(0x7f21128ca000, 2093056, PROT_NONE) = 0 mmap(0x7f2112ac9000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4c000) = 0x7f2112ac9000 mmap(0x7f2112ad4000, 3312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2112ad4000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300N\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1716576, ...}) = 0 mmap(NULL, 3828824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f21124d6000 mprotect(0x7f2112674000, 2093056, PROT_NONE) = 0 mmap(0x7f2112873000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19d000) = 0x7f2112873000 mmap(0x7f2112879000, 15448, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2112879000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2112ccf000 open("/usr/lib64/tls/x86_64/libpfm.so.4", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls/x86_64", 0x7ffd2d32b460) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/libpfm.so.4", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/tls", 0x7ffd2d32b460) = -1 ENOENT (No such file or directory) open("/usr/lib64/x86_64/libpfm.so.4", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib64/x86_64", 0x7ffd2d32b460) = -1 ENOENT (No such file or directory) open("/usr/lib64/libpfm.so.4", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \251\5\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1054784, ...}) = 0 mmap(NULL, 3155440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f21121d3000 mprotect(0x7f211226c000, 2097152, PROT_NONE) = 0 mmap(0x7f211246c000, 430080, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x99000) = 0x7f211246c000 mmap(0x7f21124d5000, 1520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f21124d5000 close(3) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2112ccd000 arch_prctl(ARCH_SET_FS, 0x7f2112ccd740) = 0 mprotect(0x7f2112873000, 16384, PROT_READ) = 0 mprotect(0x7f211246c000, 385024, PROT_READ) = 0 mprotect(0x7f2112ac9000, 4096, PROT_READ) = 0 mprotect(0x600000, 4096, PROT_READ) = 0 mprotect(0x7f2112cf5000, 4096, PROT_READ) = 0 munmap(0x7f2112cd0000, 144976) = 0 exit_group(0) = ? +++ exited with 0 +++ From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 11 23:03:06 2015 Received: (at 19997-done) by debbugs.gnu.org; 12 Mar 2015 03:03:06 +0000 Received: from localhost ([127.0.0.1]:43301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVtOr-000650-Pw for submit@debbugs.gnu.org; Wed, 11 Mar 2015 23:03:06 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:55232) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVtOp-00064U-AS for 19997-done@debbugs.gnu.org; Wed, 11 Mar 2015 23:03:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 55F6FA6002D for <19997-done@debbugs.gnu.org>; Wed, 11 Mar 2015 20:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aenG9eotVpMQ for <19997-done@debbugs.gnu.org>; Wed, 11 Mar 2015 20:02:57 -0700 (PDT) Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id F326DA60018 for <19997-done@debbugs.gnu.org>; Wed, 11 Mar 2015 20:02:56 -0700 (PDT) Message-ID: <550101E0.8060800@cs.ucla.edu> Date: Wed, 11 Mar 2015 20:02:56 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: 19997-done@debbugs.gnu.org Subject: closing bug report Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 19997-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) As the -lpapi problem is understood now to be a side-track issue, I'm closing the bug report. From unknown Mon Aug 18 04:05:39 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 09 Apr 2015 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator