Re: [Mingw-w64-public] Problem with MSYS on 64-bit
Mercurial is a revision control system (like git, svn, etc). In other
words it was fixed after the release and is in their public
repository.
You can safely ignore that particular test's error, the bug is in the
test-suite program itself. If you want to see it be clean, you could
apply the patch that I posted and rerun the test.
On Thu, Jun 10, 2010 at 5:57 PM, Chris Saunders e...@mountaincable.net wrote:
First, thanks very much for the reply Doug. I don't know what the
mercurial 5.0 branch is. Could I ask for an explenation? Also, does your
reply mean that I can ignore the error I got from make check? I used MSYS
to build MPFR using ./configure --disable-shared --host=x86_64-w64-mingw32
--with-gmp-build=/home/chris/gmp-5.0.1 and make check ran with no errors.
Regards
Chris Saunders
--
From: Doug Semler dougsem...@gmail.com
Sent: Thursday, June 10, 2010 4:21 PM
To: Chris Saunders e...@mountaincable.net
Cc: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Problem with MSYS on 64-bit
On Thu, Jun 10, 2010 at 4:10 PM, Chris Saunders e...@mountaincable.net
wrote:
The error was:
n = 97327602995864283868534915224192610...(cut this because it was very
long)
n was destroyed, but perfpow_p still believes n is a perfect power
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
FAIL: t-perfpow.exe
I had intended to include that in the message but forgot. Sorry.
Regards
Chris Saunders
That's what I figured. Note we are a long long ABI. Soo
from http://gmplib.org/
quote
There are spurious test failures with mpz/t-perfpow.c when using an
ABI where GMP uses long long for internal computations. Examples of
such ABIs are MIPS n32, HPUX 2.0n, and PowerPC mode32.
/quote
(Note that this is fixed on the mercurial 5.0 branch since February)
Patch:
# HG changeset patch
# User Torbjorn Granlund t...@gmplib.org
# Date 1267122532 -3600
# Node ID 794410151f5f966bcb5c3489b6441614990efe7c
# Parent 948660e2e56d9cfaae035082b8fd473985505fb6
Fix a test case to work for long long limbs.
diff -r 948660e2e56d -r 794410151f5f ChangeLog
--- a/ChangeLog Thu Feb 25 16:08:21 2010 +0100
+++ b/ChangeLog Thu Feb 25 19:28:52 2010 +0100
@@ -1,5 +1,8 @@
2010-02-25 Torbjorn Granlund t...@gmplib.org
+ * tests/mpz/t-perfpow.c (check_random): Use mp_limb_t type for limb
+ variables.
+
* tests/mpn/t-div.c: Cast a switch index to placate HP's cc.
* tests/mpn/t-bdiv.c: Likewise.
diff -r 948660e2e56d -r 794410151f5f tests/mpz/t-perfpow.c
--- a/tests/mpz/t-perfpow.c Thu Feb 25 16:08:21 2010 +0100
+++ b/tests/mpz/t-perfpow.c Thu Feb 25 19:28:52 2010 +0100
@@ -2,7 +2,7 @@
Contributed to the GNU project by Torbjorn Granlund and Martin Boij.
-Copyright 2008, 2009 Free Software Foundation, Inc.
+Copyright 2008, 2009, 2010 Free Software Foundation, Inc.
This file is part of the GNU MP Library.
@@ -109,7 +109,8 @@
{
mpz_t n, np, temp, primes[NRP];
int i, j, k, unique, destroy, res;
- unsigned long int nrprimes, primebits, g, exp[NRP], e;
+ unsigned long int nrprimes, primebits;
+ mp_limb_t g, exp[NRP], e;
gmp_randstate_ptr rands;
rands = RANDS;
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Dwarf-2 debugging support?
Hi there, Our project (MAME) recently converted a bunch of C code to C++, and as a result our symbol size has bloated tremendously (EXE is now 280MB(!) with symbols, versus 40MB without), killing our link times. Our cohorts on the Linux side have not noticed any significant difference. After some investigation, it looks like the difference is due to stabs versus DWARF debugging information. We are using the sezero builds. I tried forcing mingw-w32 to output DWARF-2 (via -gdwarf-2; also tried -ggdb) but the binary size ends up almost identical. I strongly suspect that the compiler was not built with support for generating DWARF symbols and is just ignoring my pleas. I know the DWARF EH model is not supported, but from what I understand, the support for DWARF debugging information is independent of the EH model. So basically: 1. Can you confirm/deny the existence of DWARF debugging support in current sezero builds? 2. Are there other builds of the 4.4.x tree we can use that have this enabled? 3. Or alternately, Ozkan, can we convince you to turn this on for your builds? :) Thanks, Aaron -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Dwarf-2 debugging support?
Our project (MAME) recently converted a bunch of C code to C++, and as a result our symbol size has bloated tremendously (EXE is now 280MB(!) with symbols, versus 40MB without), killing our link times. Our cohorts on the Linux side have not noticed any significant difference. After some investigation, it looks like the difference is due to stabs versus DWARF debugging information. We are using the sezero builds. I tried forcing mingw-w32 to output DWARF-2 (via -gdwarf-2; also tried -ggdb) but the binary size ends up almost identical. I strongly suspect that the compiler was not built with support for generating DWARF symbols and is just ignoring my pleas. I know the DWARF EH model is not supported, but from what I understand, the support for DWARF debugging information is independent of the EH model. So basically: 1. Can you confirm/deny the existence of DWARF debugging support in current sezero builds? 2. Are there other builds of the 4.4.x tree we can use that have this enabled? 3. Or alternately, Ozkan, can we convince you to turn this on for your builds? :) Thanks, Aaron Hi, you are confusing dwarf-2 debug and EH, they are different animals. DW- 2 debug is already in use with -gdwarf-2, but DW2 EH on win64 don't work at all. There have been work on SEH but its not in GCC yet. Actually, no, I'm not confusing them, as I stated above: I know the DWARF EH model is not supported, but from what I understand, the support for DWARF debugging information is independent of the EH model. Regardless, after further investigation, it appears that the dwarf-2 debugging is the default after all, but interestingly for our case -gstabs produces much smaller binaries (132MB versus 280MB). Which is contradictory to information I've read in other areas where dwarf is supposed to be much more efficient. I still believe there is a significant size discrepancy between mingw and linux here. I will gather more information to understand what is going on. Aaron -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Dwarf-2 debugging support?
Hello Aaron, 2010/6/11 Aaron Giles aa...@aarongiles.com: Our project (MAME) recently converted a bunch of C code to C++, and as a result our symbol size has bloated tremendously (EXE is now 280MB(!) with symbols, versus 40MB without), killing our link times. Our cohorts on the Linux side have not noticed any significant difference. After some investigation, it looks like the difference is due to stabs versus DWARF debugging information. We are using the sezero builds. I tried forcing mingw-w32 to output DWARF-2 (via -gdwarf-2; also tried -ggdb) but the binary size ends up almost identical. I strongly suspect that the compiler was not built with support for generating DWARF symbols and is just ignoring my pleas. I know the DWARF EH model is not supported, but from what I understand, the support for DWARF debugging information is independent of the EH model. So basically: 1. Can you confirm/deny the existence of DWARF debugging support in current sezero builds? 2. Are there other builds of the 4.4.x tree we can use that have this enabled? 3. Or alternately, Ozkan, can we convince you to turn this on for your builds? :) Thanks, Aaron Hi, you are confusing dwarf-2 debug and EH, they are different animals. DW- 2 debug is already in use with -gdwarf-2, but DW2 EH on win64 don't work at all. There have been work on SEH but its not in GCC yet. Actually, no, I'm not confusing them, as I stated above: I know the DWARF EH model is not supported, but from what I understand, the support for DWARF debugging information is independent of the EH model. Regardless, after further investigation, it appears that the dwarf-2 debugging is the default after all, but interestingly for our case -gstabs produces much smaller binaries (132MB versus 280MB). Which is contradictory to information I've read in other areas where dwarf is supposed to be much more efficient. I still believe there is a significant size discrepancy between mingw and linux here. I will gather more information to understand what is going on. Aaron -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public It is true that dwarf debugging information is much bigger in size. But in general you have here different possiblities to solve this. First of course by the debugging-level switch -gn. Additionally you can use object-copy tool to split debugging information into an separate file. The gstabs information isn't possible for x64, so I would recomment that you stick to the dwarf-2 information. In 4.4.x and 4.5.x series there are some tweak about debugging information and inlined code. To avoid this don't use debugging information (or strip them out into separate debugging file) for optimization levels = 1. Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] FLTK 1.1.10 for w64
Hello Zhau, the FLTK 1.1.x devel library on [1] is not usable. There are missing some basic libraries (libfltk.a, libfltk_images.a). I think the build was incomplete, because the GCC stops on such errors: FL/Fl_Menu_Item.H:91: error: cast from 'void*' to 'long int' loses precision fl_open_uri.cxx:117: error: cast from 'HINSTANCE__*' to 'int' loses precision I know, that is not a MinGW problem. I would only note this here, and ask for an idea to build FLTK 1.1.x with MinGW-w64. [1]http://www.drangon.org/mingw/ fltk 1.1.10 library for mingw-w64 -- Henry N. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
