Broken MPIR 2.6.0 on Cygwin64

Broken MPIR 2.6.0 on Cygwin64

[Jean-Pierre Flori]

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.


So my problem with MPIR are as follow:

* the ./configfsf.[guess|sub] and yasm/config/config.[guess|sub] file
within the upstream tarball are too old and failed to recognize
Cygwin64, replacing them with up-to-date version easily solves that,

* I have no problem building a static lib, but running make check
fails when linking any test executable, e.g. the first one
"t-bswap.exe":
{{{
/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
libtests.la ../libmpir.la
libtool: link: gcc -std=gnu99 -m64 -O2 -march=corei7-avx
-mtune=corei7-avx -o t-bswap.exe t-bswap.o  ./.libs/libtests.a
/home/jp/mpir-2.6.0/.libs/libmpir.a ../.libs/libmpir.a
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
Makefile:503: recipe for target `t-bswap.exe' failed
}}}
A 0 byte t-bswap.exe is created and the content of the stackdump is
{{{
$ cat tests/ld.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at rip=0000000003E
rax=00000001004C3FA0 rbx=000000060018DCB0 rcx=000000060018DCB0
rdx=000000060018ECA8 rsi=0000000000C2A580 rdi=0000000000000025
r8 =0000000000C2A590 r9 =00000000FFFFBFFF r10=0000000000C30000
r11=00000001004B111E r12=0000000000000001 r13=000000060018ECA9
r14=0000000100534780 r15=000000060018ECA8
rbp=0000000000C2A590 rsp=0000000000C2A528
program=C:\cygwin64\usr\x86_64-pc-cygwin\bin\ld.exe, pid 6744, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
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.


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?


Thanks in advance for your help,
Best,

-- 
Jean-Pierre Flori

--
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

Re: Broken MPIR 2.6.0 on Cygwin64

[Corinna Vinschen]

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

Re: Broken MPIR 2.6.0 on Cygwin64

[Corinna Vinschen]

On Jun 21 10:30, Corinna Vinschen wrote:
> On Jun 21 00:39, Jean-Pierre Flori wrote:
> > [...]
> > /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.

Btw., if you install the binutils-debuginfo package, you can also
evaluate the addresses within ld on the top of the stack:

$ addr2line -e /usr/lib/debug/usr/bin/ld.exe.dbg 00100493B54 00100433783 0010040E82C 0010040F2E0 001004113FB 001004BF4C0
/usr/src/debug/binutils-2.23.52-5/bfd/cofflink.c:219
/usr/src/debug/binutils-2.23.52-5/bfd/linker.c:1132
/usr/src/debug/binutils-2.23.52-5/ld/ldlang.c:2795
/usr/src/debug/binutils-2.23.52-5/ld/ldlang.c:3257
/usr/src/debug/binutils-2.23.52-5/ld/ldlang.c:6606
/usr/src/debug/binutils-2.23.52-5/ld/ldmain.c:415

But I admit this doesn;'t help a lot either, if you don't know why it
crashed at this point.


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

Re: Broken MPIR 2.6.0 on Cygwin64

[Jean-Pierre Flori]

Hey,

Thanks for the quick reply.

Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :

>> /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?

This is automatically determined by the configure script, I get the same 
for GMP, it actually corresponds to my CPU, and works fine on Linux.
Anyway, I've also tried with only "-m64 -O0 -g" and got similar results.

> 
> 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.
> 
It's an option.
I'll try to do that today.


Best,
JP


--
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

Re: Broken MPIR 2.6.0 on Cygwin64

[Corinna Vinschen]

On Jun 21 09:27, Jean-Pierre Flori wrote:
> Hey,
> 
> Thanks for the quick reply.
> 
> Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
> 
> >> /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?
> 
> This is automatically determined by the configure script, I get the same 
> for GMP, it actually corresponds to my CPU, and works fine on Linux.
> Anyway, I've also tried with only "-m64 -O0 -g" and got similar results.
> 
> > 
> > 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.
> > 
> It's an option.
> I'll try to do that today.

The easiest way to do that is to fetch the binutils-2.23.52-5 source
package from a Cygwin mirror and to use cygport for building.  Just
tweak the cygport file to set MAKEOPTS to 'CFLAGS=-g'.


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

libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Corinna Vinschen]

Hi Chuck, Hi Yaakov,

as our resident autotools/libtool experts, could you please have a
look here?

On Jun 21 11:43, Corinna Vinschen wrote:
> On Jun 21 09:27, Jean-Pierre Flori wrote:
> > Hey,
> > 
> > Thanks for the quick reply.
> > 
> > Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
> > 
> > >> /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?
> > 
> > This is automatically determined by the configure script, I get the same 
> > for GMP, it actually corresponds to my CPU, and works fine on Linux.
> > Anyway, I've also tried with only "-m64 -O0 -g" and got similar results.
> > 
> > > 
> > > 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.
> > > 
> > It's an option.
> > I'll try to do that today.
> 
> The easiest way to do that is to fetch the binutils-2.23.52-5 source
> package from a Cygwin mirror and to use cygport for building.  Just
> tweak the cygport file to set MAKEOPTS to 'CFLAGS=-g'.

For testing I created a simple cygport file to build mpir 2.6.0:

  NAME="mpir"
  VERSION="2.6.0"
  RELEASE=1
  CATEGORY="Math"
  SUMMARY="MPIR"
  DESCRIPTION="MPIR"
  SRC_URI="http://www.mpir.org/${P}.tar.bz2"

Then I tried to build it.  Of course, cygport autoreconfs and our
libtool version 2.4.2 is installed.  Configure runs fine.

When building, first it failed to build in the mpn subdir, because it
accidentally calls yasm with the -f elf64 flag.  I fixed that locally by
tweaking mpn/Makefile by setting OBJECT_FORMAT from -f elf64 to -f
win64.  There's also the problem that libtool adds the -DPIC flag and
this leads to using the wrong code path in mpn/modexact_1c_odd.as.
Change lines 107ff to

  ;%ifdef PIC
  ;    mov      r9, [mod_table wrt rip wrt ..gotpcrel]
  ;%else
      lea      r9, [mod_table wrt rip]
  ;%endif

effectively disabling the GOT table access, then it builds.

But that's just a minor inconvenience, the real problem comes in the
final link stage.  When trying to link libmpir.la, something weird happens.
The libtool command line is basically this:

  /bin/sh ./libtool --tag=CC    --mode=link gcc -std=gnu99  \
  -ggdb -O2 -pipe -fdebug-prefix-map=[...] -fdebug-prefix-map=[...] \
  -no-undefined -Wl,--export-all-symbols \
  -Wl,--output-def,.libs/libmpir-3.dll.def \
  -version-info 11:0 :5  \
  -o libmpir.la -rpath \
  [loooooong list of .lo files]

This gets converted by libtool into the following calls:

  libtool: link: /usr/x86_64-pc-cygwin/bin/ld.exe -r -o .libs/libmpir.la-1.o \
  [long list of .o files]
  libtool: link: /usr/x86_64-pc-cygwin/bin/ld.exe -r -o .libs/libmpir.la-2.o \
  [second long list of .o files]
  libtool: link: rm -f .libs/libmpir.la-1.o
  libtool: link: gcc -std=gnu99 -shared .libs/libmpir.la-2.o   -O2 \
  -Wl,--export-all-symbols -Wl,--output-def -Wl,.libs/libmpir-3.dll.def   \
  -o .libs/libmpir-11.dll \				# Problem 2
  -Wl,--enable-auto-image-base \
  -Xlinker --out-implib -Xlinker .libs/libmpir-11.dll	# Problem 1

This result has two big problems I never encountered with libtool before,
and one problem which is probably just a followup issue:

Problem 1:

  The final call fails with

    Can't open .lib file: .libs/libmpir-11.dll

  The reason is the final -Xlinker option, which uses the wrong filename for
  the import lib.  That should be .libs/libmpir-11.dll.a.  I have found no
  way to tweak the libtool command line so that the -Xlinker option is
  either omitted, or so that it uses the correct filename.

  How can this be fixed?

Problem 2:

  Even when running the last stage of the build by hand, replacing
  .libs/libmpir-11.dll with .libs/libmpir-11.dll.a, the fact remains
  that the result will be called libmpir-11.dll, rather than the
  usual cygmpir-11.dll.

  Why does libtool generate the wrong filename here?

Problem 3:

  Even when running the last stage of the build by hand as described
  above, the final result will NOT have generated a libmpir.la file.
  This in turn disallows to run the testsuite, which requires the .la
  file to exist.

  What's missing to create the .la file here?


Thanks for any help,
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

Re: Broken MPIR 2.6.0 on Cygwin64

[Jean-Pierre Flori]

Le Fri, 21 Jun 2013 11:43:44 +0200, Corinna Vinschen a écrit :

> On Jun 21 09:27, Jean-Pierre Flori wrote:
>> Hey,
>> 
>> Thanks for the quick reply.
>> 
>> Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
>> 
>> >> /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
>>
> The easiest way to do that is to fetch the binutils-2.23.52-5 source
> package from a Cygwin mirror and to use cygport for building.  Just
> tweak the cygport file to set MAKEOPTS to 'CFLAGS=-g'.
> 
I did it using configure/make/make install directly.
Here is the backtrace I got (when trying to build a static library, first 
of the unsolved problems I reported):

Program received signal SIGSEGV, Segmentation fault.
0x000000000000003e in ?? ()
(gdb) bt
#0  0x000000000000003e in ?? ()
#1  0x0000000100499ece in coff_link_check_ar_symbols (abfd=0x60013d1c0,
    info=0x10058a720 <link_info>, pneeded=0xc2a6fc, subsbfd=0xc2a6d0)
    at cofflink.c:217
#2  0x000000010049a08f in coff_link_check_archive_element 
(abfd=0x60013d1c0,
    info=0x10058a720 <link_info>, pneeded=0xc2a6fc) at cofflink.c:279
#3  0x000000010044cced in _bfd_generic_link_add_archive_symbols (
    abfd=0x600081170, info=0x10058a720 <link_info>,
    checkfn=0x10049a03e <coff_link_check_archive_element>) at 
linker.c:1132
#4  0x0000000100499daf in _bfd_coff_link_add_symbols (abfd=0x600081170,
    info=0x10058a720 <link_info>) at cofflink.c:169
#5  0x000000010040fe6f in load_symbols (entry=0x60003ac00, place=0xc2a880)
    at ldlang.c:2795
#6  0x0000000100410b66 in open_input_bfds (s=0x60003ac00, 
mode=OPEN_BFD_NORMAL)
    at ldlang.c:3257
#7  0x0000000100416ee9 in lang_process () at ldlang.c:6603
#8  0x000000010041b2d3 in main (argc=7, argv=0xc2aa60) at ./ldmain.c:411

Best,
JP


--
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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Jean-Pierre Flori]

Hi all,

Here is my experience with a shared version of the library after taking 
Corinna's message into account, starting from a clean MPIR tarball (except 
for updating the FSF config.sub/guess) without autoreconfing, and using 
the Cygwin shipped yasm rather than the one included in MPIR (in case the 
Cygwin one has patches).

Le Fri, 21 Jun 2013 13:33:57 +0200, Corinna Vinschen a écrit :
> Then I tried to build it.  Of course, cygport autoreconfs and our
> libtool version 2.4.2 is installed.  Configure runs fine.
> 
> When building, first it failed to build in the mpn subdir, because it
> accidentally calls yasm with the -f elf64 flag.  I fixed that locally by
> tweaking mpn/Makefile by setting OBJECT_FORMAT from -f elf64 to -f
The -f elf64 did not make the build fail, but as this suggests I changed 
it to -f win64...
> win64.  There's also the problem that libtool adds the -DPIC flag and
> this leads to using the wrong code path in mpn/modexact_1c_odd.as.
> Change lines 107ff to
> 
>   ;%ifdef PIC ;    mov      r9, [mod_table wrt rip wrt ..gotpcrel]
>   ;%else
>       lea      r9, [mod_table wrt rip]
>   ;%endif
> 
...what make compiling modexact_1c_odd.as fail (which it did not with -f 
elf64).
Same workaround solves the problem.
> effectively disabling the GOT table access, then it builds.
> 
> But that's just a minor inconvenience, the real problem comes in the
> final link stage.  When trying to link libmpir.la, something weird
> happens.
> The libtool command line is basically this:
> 
>   /bin/sh ./libtool --tag=CC    --mode=link gcc -std=gnu99  \
>   -ggdb -O2 -pipe -fdebug-prefix-map=[...] -fdebug-prefix-map=[...] \
>   -no-undefined -Wl,--export-all-symbols \
>   -Wl,--output-def,.libs/libmpir-3.dll.def \
>   -version-info 11:0 :5  \
>   -o libmpir.la -rpath \
>   [loooooong list of .lo files]
> 
> This gets converted by libtool into the following calls:
> 
>   libtool: link: /usr/x86_64-pc-cygwin/bin/ld.exe -r -o
>   .libs/libmpir.la-1.o \
>   [long list of .o files]
>   libtool: link: /usr/x86_64-pc-cygwin/bin/ld.exe -r -o
>   .libs/libmpir.la-2.o \
>   [second long list of .o files]
>   libtool: link: rm -f .libs/libmpir.la-1.o libtool: link: gcc
>   -std=gnu99 -shared .libs/libmpir.la-2.o   -O2 \
>   -Wl,--export-all-symbols -Wl,--output-def -Wl,.libs/libmpir-3.dll.def 
>    \ -o .libs/libmpir-11.dll \				# Problem 
2
>   -Wl,--enable-auto-image-base \
>   -Xlinker --out-implib -Xlinker .libs/libmpir-11.dll	# Problem 1
> 
As before I don't have these two problems (not autoreconf in my case) and 
get correct cygmpir.dll and libmpir.dll.a.

I also corrected elf64 to win64 in tests/Makefile as yasm is used there 
as well.

And the bad news is: tests still segfault.

I'll also check with the static library now.

I'll also check without assembly optimizations, or lowering gcc 
optimization level, etc.

Best and thanks for the help!
Hopefully you can come up with proper fixes to the build system (to use -f 
win64 and no -DPIC) and the rest will follow.

JP


--
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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Jean-Pierre Flori]

Le Fri, 21 Jun 2013 16:56:23 +0000, Jean-Pierre Flori a écrit :
> And the bad news is: tests still segfault.
> 
> I'll also check with the static library now.
> 
With the same changes but trying a static lib I get to the same point as 
for the shared one:
* ld doesn't segfault anymore, so tests executables are built,
* but the same tests as in the shared library setting segfault.

> I'll also check without assembly optimizations, or lowering gcc
> optimization level, etc.
So I'm going to try that now.


--
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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Jean-Pierre Flori]

Le Fri, 21 Jun 2013 17:06:03 +0000, Jean-Pierre Flori a écrit :

>> I'll also check without assembly optimizations, or lowering gcc
>> optimization level, etc.
> So I'm going to try that now.
If i disable ASM routines by passing MPN_PATH=generic to configure, then 
(in the static setting at least) most tests now pass.



--
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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Yaakov (Cygwin/X)]

On 2013-06-21 06:33, Corinna Vinschen wrote:
> as our resident autotools/libtool experts, could you please have a
> look here?

The problem is, as a fork of GMP, it too tries to be too clever with 
libtool in an attempt to shorten configure times by avoiding the CXX/F77 
checks.  Those hacks are not only unnecessary with libtool 2.x, they are 
incompatible with it.

Run the following to remove the offending 25 lines of configure:

sed -i -e '/# Enable CXX/,/AC_PROVIDE/d' configure.in

Then you still need to teach configure.in about Cygwin wrt -f 
win32/win64 and which asm sources to use before running (cyg)autoreconf.


Yaakov


--
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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Jean-Pierre Flori]

Le Fri, 21 Jun 2013 17:27:22 +0000, Jean-Pierre Flori a écrit :

> Le Fri, 21 Jun 2013 17:06:03 +0000, Jean-Pierre Flori a écrit :
> 
>>> I'll also check without assembly optimizations, or lowering gcc
>>> optimization level, etc.
>> So I'm going to try that now.
> If i disable ASM routines by passing MPN_PATH=generic to configure, then
> (in the static setting at least) most tests now pass.

Using the default MPN_PATH I get "x86_64/sandybridge x86_64 generic", the 
first segfault I get is in the first test in the mpn dir: t-addadd_n.c.
GDB points to the loop1() function:

jp@napoleon-7 ~/mpir-2.6.0/tests/mpn
$ gdb t-addadd_n.exe
GNU gdb (GDB) 7.6.50.20130320-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/
gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/jp/mpir-2.6.0/tests/mpn/t-addadd_n.exe...done.
(gdb) r
Starting program: /home/jp/mpir-2.6.0/tests/mpn/t-addadd_n.exe
[New Thread 2576.0x9b8]
[New Thread 2576.0x398]

Program received signal SIGSEGV, Segmentation fault.
0x00000001004020ae in loop1 ()
(gdb) bt
#0  0x00000001004020ae in loop1 ()
#1  0x0000000100401fe7 in __gmpn_addadd_n (t=0x1c8fc0, x=<optimized out>,
    y=<optimized out>, z=<optimized out>, n=1) at addadd_n.c:50
#2  0x0000000100425fb6 in main () at t-addadd_n.c:58

apparently coming from add_n.as.
If someone sees something wrong in the asm files, I have no experience 
with them.


--
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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Jean-Pierre Flori]

Le Fri, 21 Jun 2013 18:07:00 +0000, Jean-Pierre Flori a écrit :

> Le Fri, 21 Jun 2013 17:27:22 +0000, Jean-Pierre Flori a écrit :
> 
>> Le Fri, 21 Jun 2013 17:06:03 +0000, Jean-Pierre Flori a écrit :
>> 
>>>> I'll also check without assembly optimizations, or lowering gcc
>>>> optimization level, etc.
>>> So I'm going to try that now.
>> If i disable ASM routines by passing MPN_PATH=generic to configure,
>> then (in the static setting at least) most tests now pass.
> 
> Using the default MPN_PATH I get "x86_64/sandybridge x86_64 generic",
> the first segfault I get is in the first test in the mpn dir:
> t-addadd_n.c. GDB points to the loop1() function:
> 
> jp@napoleon-7 ~/mpir-2.6.0/tests/mpn $ gdb t-addadd_n.exe GNU gdb (GDB)
> 7.6.50.20130320-cvs Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/
> gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-cygwin".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from
> /home/jp/mpir-2.6.0/tests/mpn/t-addadd_n.exe...done. (gdb) r Starting
> program: /home/jp/mpir-2.6.0/tests/mpn/t-addadd_n.exe [New Thread
> 2576.0x9b8]
> [New Thread 2576.0x398]
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000001004020ae in loop1 ()
> (gdb) bt #0  0x00000001004020ae in loop1 ()
> #1  0x0000000100401fe7 in __gmpn_addadd_n (t=0x1c8fc0, x=<optimized
> out>,
>     y=<optimized out>, z=<optimized out>, n=1) at addadd_n.c:50
> #2  0x0000000100425fb6 in main () at t-addadd_n.c:58
> 
> apparently coming from add_n.as.
> If someone sees something wrong in the asm files, I have no experience
> with them.

Ok, I think I got it.
The asm code in the x86_64 dir and subdirs expects System V AMD64 ABI for 
argument passing (so first int or pointer in rdi and so on), but of 
course on win64 the convention is different so this is fundamentally 
incompatible.

Now there is also a x86_64w dir for windows assembly but yasm does not 
like its syntax.
I'll be looking into that.


--
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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Jean-Pierre Flori]

Le Fri, 21 Jun 2013 22:10:15 +0000, Jean-Pierre Flori a écrit :
> Now there is also a x86_64w dir for windows assembly but yasm does not
> like its syntax.
> I'll be looking into that.
In fact its not yasm which is used I guess.
We should indeed use the *w directories and basically do quite everything 
like for mingw64...


--
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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Corinna Vinschen]

On Jun 21 16:56, Jean-Pierre Flori wrote:
> Hi all,
> 
> Here is my experience with a shared version of the library after taking 
> Corinna's message into account, starting from a clean MPIR tarball (except 
> for updating the FSF config.sub/guess) without autoreconfing, and using 
> the Cygwin shipped yasm rather than the one included in MPIR (in case the 
> Cygwin one has patches).
> 
> Le Fri, 21 Jun 2013 13:33:57 +0200, Corinna Vinschen a écrit :
> > Then I tried to build it.  Of course, cygport autoreconfs and our
> > libtool version 2.4.2 is installed.  Configure runs fine.
> > 
> > When building, first it failed to build in the mpn subdir, because it
> > accidentally calls yasm with the -f elf64 flag.  I fixed that locally by
> > tweaking mpn/Makefile by setting OBJECT_FORMAT from -f elf64 to -f
> The -f elf64 did not make the build fail, but as this suggests I changed 
> from the memory of all my collegues. it to -f win64...

It made the build fail for me in the link stage, because ld complained
about trying to link ELF with PE/COFF.


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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Corinna Vinschen]

On Jun 21 22:44, Jean-Pierre Flori wrote:
> Le Fri, 21 Jun 2013 22:10:15 +0000, Jean-Pierre Flori a écrit :
> > Now there is also a x86_64w dir for windows assembly but yasm does not
> > like its syntax.
> > I'll be looking into that.
> In fact its not yasm which is used I guess.
> We should indeed use the *w directories and basically do quite everything 
> like for mingw64...

That makes sense as far as the assembler code goes, but you have to
be careful about type differences.  Mingw-w64 has 4 byte longs (LLP64),
Cygwin has 8 byte longs (LP64).


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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Corinna Vinschen]

On Jun 21 12:57, Yaakov (Cygwin/X) wrote:
> On 2013-06-21 06:33, Corinna Vinschen wrote:
> >as our resident autotools/libtool experts, could you please have a
> >look here?
> 
> The problem is, as a fork of GMP, it too tries to be too clever with
> libtool in an attempt to shorten configure times by avoiding the
> CXX/F77 checks.  Those hacks are not only unnecessary with libtool
> 2.x, they are incompatible with it.
> 
> Run the following to remove the offending 25 lines of configure:
> 
> sed -i -e '/# Enable CXX/,/AC_PROVIDE/d' configure.in
> 
> Then you still need to teach configure.in about Cygwin wrt -f
> win32/win64 and which asm sources to use before running
> (cyg)autoreconf.

Oh, cool, thanks!  I'll have to look into other stuff first, but I'll
probably have a look later this week.  An ld crash is never really a
good idea.


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

Re: Broken MPIR 2.6.0 on Cygwin64

[Corinna Vinschen]

On Jun 21 13:30, Jean-Pierre Flori wrote:
> Le Fri, 21 Jun 2013 11:43:44 +0200, Corinna Vinschen a écrit :
> 
> > On Jun 21 09:27, Jean-Pierre Flori wrote:
> >> Hey,
> >> 
> >> Thanks for the quick reply.
> >> 
> >> Le Fri, 21 Jun 2013 10:30:39 +0200, Corinna Vinschen a écrit :
> >> 
> >> >> /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
> >>
> > The easiest way to do that is to fetch the binutils-2.23.52-5 source
> > package from a Cygwin mirror and to use cygport for building.  Just
> > tweak the cygport file to set MAKEOPTS to 'CFLAGS=-g'.
> > 
> I did it using configure/make/make install directly.
> Here is the backtrace I got (when trying to build a static library, first 
> of the unsolved problems I reported):
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000000003e in ?? ()
> (gdb) bt
> #0  0x000000000000003e in ?? ()
> #1  0x0000000100499ece in coff_link_check_ar_symbols (abfd=0x60013d1c0,
>     info=0x10058a720 <link_info>, pneeded=0xc2a6fc, subsbfd=0xc2a6d0)
>     at cofflink.c:217
> #2  0x000000010049a08f in coff_link_check_archive_element 
> (abfd=0x60013d1c0,
>     info=0x10058a720 <link_info>, pneeded=0xc2a6fc) at cofflink.c:279

Unfortunately this doesn't tell as why it crashes.  Is that with the
wrong assembler files?  Does it work when using the correct assembler
files?


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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Corinna Vinschen]

On Jun 24 11:20, Corinna Vinschen wrote:
> On Jun 21 12:57, Yaakov (Cygwin/X) wrote:
> > On 2013-06-21 06:33, Corinna Vinschen wrote:
> > >as our resident autotools/libtool experts, could you please have a
> > >look here?
> > 
> > The problem is, as a fork of GMP, it too tries to be too clever with
> > libtool in an attempt to shorten configure times by avoiding the
> > CXX/F77 checks.  Those hacks are not only unnecessary with libtool
> > 2.x, they are incompatible with it.
> > 
> > Run the following to remove the offending 25 lines of configure:
> > 
> > sed -i -e '/# Enable CXX/,/AC_PROVIDE/d' configure.in
> > 
> > Then you still need to teach configure.in about Cygwin wrt -f
> > win32/win64 and which asm sources to use before running
> > (cyg)autoreconf.
> 
> Oh, cool, thanks!  I'll have to look into other stuff first, but I'll
> probably have a look later this week.  An ld crash is never really a
> good idea.

This seem to have been a problem with the assembler files, but I can't
reproduce it if I use the right settings.  With this cygport file:

  NAME="mpir"
  VERSION="2.6.0"
  RELEASE=1
  CATEGORY="Math"
  SUMMARY="MPIR"
  DESCRIPTION="MPIR"
  SRC_URI="http://www.mpir.org/${P}.tar.bz2"

and with this patch to configure.in:

--- origsrc/mpir-2.6.0/configure.in	2012-11-08 23:10:45.000000000 +0100
+++ src/mpir-2.6.0/configure.in	2013-06-24 13:01:45.471254358 +0200
@@ -1904,32 +1904,6 @@ if test -z "$CONFIG_SHELL"; then
   CONFIG_SHELL=$SHELL
 fi
 
-# Enable CXX in libtool only if we want it, and never enable GCJ, nor RC on
-# mingw and cygwin.  Under --disable-cxx this avoids some error messages
-# from libtool arising from the fact we didn't actually run AC_PROG_CXX.
-# Notice that any user-supplied --with-tags setting takes precedence.
-#
-# FIXME: Is this the right way to get this effect?  Very possibly not, but
-# the current _LT_AC_TAGCONFIG doesn't really suggest an alternative.
-#
-if test "${with_tags+set}" != set; then
-  if test $want_cxx = yes; then
-    with_tags=CXX
-  else
-    with_tags=
-  fi
-fi
-
-# The dead hand of AC_REQUIRE makes AC_PROG_LIBTOOL expand and execute
-# AC_PROG_F77, even when F77 is not in the selected with_tags.  This is
-# probably harmless, but it's unsightly and bloats our configure, so pretend
-# AC_PROG_F77 has been expanded already.
-#
-# FIXME: Rumour has it libtool will one day provide a way for a configure.in
-# to say what it wants from among supported languages etc.
-#
-AC_PROVIDE([AC_PROG_F77])
-
 AC_PROG_LIBTOOL
 
 # Generate an error here if attempting to build both shared and static when
@@ -2829,7 +2803,7 @@ if test "$gmp_asm_syntax_testing" != no;
           case $host in 
             *-*-darwin*)
               OBJECT_FORMAT="-f macho64" ;;
-	    *-w64-mingw*)
+	    *-w64-mingw*|*-pc-cygwin*)
 		OBJECT_FORMAT="-f x64"  ;;
 	    *)
 	      OBJECT_FORMAT="-f elf64" ;;

the package is built completely.  11 out of 48 tests segfault, but that
has nothing to do with ld and, as such, has been left as an excercise
for the reader.  I'm pretty sure it has something to do with the LLP64
vs LP64 difference between mingw and Cygwin 64 bit toolchain.

There's also still the problem that the DLL is installed into usr/lib
rather than usr/bin and that it's using the "lib" prefix rather than
the "cyg" prefix, but I'm sure this is fixable as well.


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

Re: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)

[Yaakov (Cygwin/X)]

On 2013-06-24 06:31, Corinna Vinschen wrote:
> This seem to have been a problem with the assembler files, but I can't
> reproduce it if I use the right settings.  With this cygport file:
>
>    NAME="mpir"
>    VERSION="2.6.0"
>    RELEASE=1
>    CATEGORY="Math"
>    SUMMARY="MPIR"
>    DESCRIPTION="MPIR"
>    SRC_URI="http://www.mpir.org/${P}.tar.bz2"
>
> and with this patch to configure.in:
[snip]
> the package is built completely.  11 out of 48 tests segfault, but that
> has nothing to do with ld and, as such, has been left as an excercise
> for the reader.  I'm pretty sure it has something to do with the LLP64
> vs LP64 difference between mingw and Cygwin 64 bit toolchain.

I concur.

> There's also still the problem that the DLL is installed into usr/lib
> rather than usr/bin and that it's using the "lib" prefix rather than
> the "cyg" prefix, but I'm sure this is fixable as well.

Ah, you also need to configure with --enable-cxx, otherwise the 
AC_PROG_CXX needs to be moved outside the conditional; do either of 
those, and the DLL will be built named correctly.


Yaakov


--
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