This is the mail archive of the
mailing list for the Cygwin project.
Re: Broken MPIR 2.6.0 on Cygwin64
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 21 Jun 2013 10:30:39 +0200
- Subject: Re: Broken MPIR 2.6.0 on Cygwin64
- References: <CAHhGz88vEgzz1i4sUjE0ugNzaf+j++r1_qT=Y6abMaB4_F=PCg at mail dot gmail dot com>
- Reply-to: cygwin at cygwin dot com
On Jun 21 00:39, Jean-Pierre Flori wrote:
> Dear all,
> First thanks a lot for your hard work on the Cygwin project and the
> Cygwin64 project.
> I've begun to try to build Sage (http://www.sagemath.org) on Cygwin64
> to provide some Windows support without the need of a virtual machine
> running Linux and now have some trouble compiling a working MPIR 2.6.0
> (http://www.mpir.org) library.
> Note that I have no problems building a proper static or shared
> version of GMP 5.1.2 with the GCC 4.8.1 toolchain currently provided
> with Cygwin64, and it passes its complete testsuite.
> At some point we should be able to switch to GMP, but we still have
> some dependencies relying on MPIR's internals, so we have (and want,
> even in the future by default) to stick with MPIR.
> Also note we have no problem using MPIR on 32 bit Cygwin.
> /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -m64 -O2
> -march=corei7-avx -mtune=corei7-avx -o t-bswap.exe t-bswap.o
Uhm, are you sure this arch and tune options aren't the problem here?
> Stack trace:
> Frame Function Args
> 00000C2A590 0000000003E (00000000000, 01300000001, 00100512180, 00000000000)
> 00000C2A590 00100493B54 (00000000000, 006000F4B30, 00000000023, 00000000000)
> 00000C2A650 00100433783 (00100534780, 00600057550, 001800C0C2C, 00000000000)
> 00000000000 0010040E82C (00600022D10, 00600023CF8, 00100436389, 00000000000)
> 00000000001 0010040F2E0 (001802DE300, 00600019870, 001800C0C2C, 00600017A30)
> 001004DDD08 001004113FB (00100520580, 00000000000, 001802E3E9D, 001802DF658)
> 001004DDD08 001004BF4C0 (00000C2A9B0, 00000C2AA46, 001801691B1, 00000000000)
> 00000C2AB80 0018004836E (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000 0018004618B (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000 0018004634F (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000 001004BDD31 (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000 00100401010 (00000000000, 00000000000, 00000000000, 00000000000)
> 00000000000 00076B7652D (00000000000, 00000000000, 00000000000, 00076BF9300)
> 00000000000 0007726C521 (00000000000, 00000000000, 00000000000, 00076BF9300)
> End of stack trace
> * I have no problem building a shared lib, nor the test programs in
> that case, but many (but not all) of them segfaults when they are run.
> In the two above cases, I was not able to retrieve useful information
> when attaching gdb to the segfaulting process.
> I just saw that three threads were launched and the backtrace only
> involved Cygwin/Windows dlls.
The function addresses on the top of the stack (starting with 0x0010...)
are well within ld. The Cygwin DLL seems to be involved only in so much
as the application's (ld's) main routine has been called.
Of course, a call stack doesn't show the actual problem, which could
easily be a weird value returned from a POSIX function inside Cygwin.
But this looks pretty much like a border case, given how many packages
we already created for 64 bit Cygwin.
> Did anyone among the Cygwin folk tried to build MPIR on Cygwin64 and
> got more success than I had?
> Or has any advice to solve these issues?
Is building the binutils package yourself and without optimization, but
with all debug symbols available an option for you? This should help
to track down the problem.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple