This is the mail archive of the
mailing list for the Cygwin project.
libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Cc: Charles Wilson <cygwin at cwilson dot fastmail dot fm>, Yaakov S <yselkowitz at users dot sourceforge dot net>
- Date: Fri, 21 Jun 2013 13:33:57 +0200
- Subject: libtool weirdness (was Re: Broken MPIR 2.6.0 on Cygwin64)
- References: <CAHhGz88vEgzz1i4sUjE0ugNzaf+j++r1_qT=Y6abMaB4_F=PCg at mail dot gmail dot com> <20130621083039 dot GH1620 at calimero dot vinschen dot de> <kq1694$ung$1 at ger dot gmane dot org> <20130621094344 dot GB25850 at calimero dot vinschen dot de>
- Reply-to: cygwin at cygwin dot com
Hi Chuck, Hi Yaakov,
as our resident autotools/libtool experts, could you please have a
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:
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
; mov r9, [mod_table wrt rip wrt ..gotpcrel]
lea r9, [mod_table wrt rip]
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 \
-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
-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:
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?
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
Why does libtool generate the wrong filename here?
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 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