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
