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

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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