Broken MPIR 2.6.0 on Cygwin64

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Jun 21 08:33:00 GMT 2013


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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list