DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=X3EQUIYGjbZbAtdGzgXsIoQY3lc+KkjciPt6PNUDaCOz4Nf4e9VXO
	LtTP1ODVhBnNJnNx0X1isbKP39G4gXhTgFXlmeKm3omJBbg1/eC14tw6FTruW8XR
	rQMxzg/ZBO036Jgu3N8MWQjPHSW2T7jHzKgtkhAm1E9F+F5pp9zzlQ=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 21 Jun 2013 10:30:39 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Broken MPIR 2.6.0 on Cygwin64
Message-ID: <20130621083039.GH1620@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CAHhGz88vEgzz1i4sUjE0ugNzaf+j++r1_qT=Y6abMaB4_F=PCg AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHhGz88vEgzz1i4sUjE0ugNzaf+j++r1_qT=Y6abMaB4_F=PCg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

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