Re: [sage-windows] Re: Cygwin attempt with sage-4.8.alpha3
Bill Hart
On 3 December 2011 19:08, kcrisman <kcri...@gmail.com> wrote:
>
>
> On Dec 3, 1:08 pm, kcrisman <kcris...@gmail.com> wrote:
>> I have a repeatable failure. This is presumably due to the MPIR
>> upgrade in 4.8.alpha0, seehttp://trac.sagemath.org/sage_trac/ticket/8664,
>
> Ah, I'm pretty sure yes.
>
>> configure: error: cannot build both static and DLL, since mpir.h is
>> different for each.
>> Use "--disable-static --enable-shared" to build just a DLL.
>> Error configuring MPIR. (See above for the options passed to it.)
>
> From the diff from mpir-2.1.3.p0-p1:
>
> - SAGE_CONF_OPTS="--enable-shared --disable-static"
> + # Also build the static library to be used by e.g. ECM:
> + # SAGE_CONF_OPTS="--enable-shared --disable-static"
> + SAGE_CONF_OPTS="--enable-shared --enable-static"
> + # (Further options to 'configure' are added below.)
>
> I'm cc:ing this to sage-devel in case the folks who added this have
> any ideas of how to fix it. I assume that going back to the --disable-
> static is not possible.
>
> If there's still a copy of mpir-2.1.3.p0 hanging around in someone's
> sage.math home directory, I could try that to make sure this really is
> the problem, for instance.
>
> I've also added a short note on #8664.
>
> - kcrisman
>
> --
> You received this message because you are subscribed to the Google Groups "sage-windows" group.
> To post to this group, send email to sage-w...@googlegroups.com.
> To unsubscribe from this group, send email to sage-windows...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-windows?hl=en.
>
Jason
> Forwarding to MPIR devel, where it might get some attention.
>
> On 3 December 2011 19:08, kcrisman <kcri...@gmail.com> wrote:
> >
> >
> > On Dec 3, 1:08 pm, kcrisman <kcris...@gmail.com> wrote:
> >> I have a repeatable failure. This is presumably due to the MPIR
> >> upgrade in 4.8.alpha0, seehttp://trac.sagemath.org/sage_trac/ticket/8664,
> >
> > Ah, I'm pretty sure yes.
> >
> >> configure: error: cannot build both static and DLL, since mpir.h is
> >> different for each.
> >> Use "--disable-static --enable-shared" to build just a DLL.
> >> Error configuring MPIR. (See above for the options passed to it.)
> >
This has always been the case for all windows systems , ie MSVC , cygwin , MSYS , and even interex.
I don't think it's possible to make mpir.h independent of dll vs static builds, it basically has to be done in the makefile/build solution
Cactus
Jason
Aha , only for cygwin and MSYS then which use the autotools , as in configure.in we have this
# Configs for Windows DLLs.
AC_LIBTOOL_WIN32_DLL
AC_SUBST(LIBGMP_DLL,0)
case $host in
*-*-cygwin* | *-*-mingw*)
# By default, build only static.
if test -z "$enable_shared"; then
enable_shared=no
fi
# Don't allow both static and DLL.
if test "$enable_shared" != no && test "$enable_static" != no; then
AC_MSG_ERROR([cannot build both static and DLL, since mpir.h is different for each.
Use "--disable-static --enable-shared" to build just a DLL.])
fi
# "-no-undefined" is required when building a DLL, see documentation on
# AC_LIBTOOL_WIN32_DLL.
#
# "-Wl,--export-all-symbols" is a bit of a hack, it gets all libmpir and
# libmpirxx functions and variables exported. This is what libtool did
# in the past, and it's convenient for us in the test programs.
#
# Maybe it'd be prudent to check for --export-all-symbols before using
# it, but it seems to have been in ld since at least 2000, and there's
# not really any alternative we want to take up at the moment.
#
# "-Wl,output-def" is used to get a .def file for use by MS lib to make
# a .lib import library, described in the manual. libmpir-3.dll.def
# corresponds to the libmp-3.dll.def generated by libtool (as a result
# of -export-symbols on that library).
#
# Incidentally, libtool does generate an import library libmpir.dll.a,
# but it's "ar" format and cannot be used by the MS linker. There
# doesn't seem to be any GNU tool for generating or converting to .lib.
#
# FIXME: The .def files produced by -Wl,output-def include isascii,
# iscsym, iscsymf and toascii, apparently because mingw ctype.h doesn't
# inline isascii (used in gmp). It gives an extern inline for
# __isascii, but for some reason not the plain isascii.
#
# LDFLAGS="$LDFLAGS -Wl,--enable-auto-import" this is too general
if test "$enable_shared" = yes; then
GMP_LDFLAGS="$GMP_LDFLAGS -no-undefined -Wl,--export-all-symbols"
LIBGMP_LDFLAGS="$LIBGMP_LDFLAGS -Wl,--output-def,.libs/libmpir-3.dll.def"
LIBGMPXX_LDFLAGS="$LIBGMP_LDFLAGS -Wl,--output-def,.libs/libmpirxx-3.dll.def"
LIBGMP_DLL=1
fi
;;
esac
and note there are a few other systems which also can't build both types at the same time
Jason
Jason
> On Saturday 03 December 2011 22:46:46 kcrisman wrote:
> >
> > > > > On Dec 3, 1:08 pm, kcrisman <kcris...@gmail.com> wrote:
> > > > >> I have a repeatable failure. This is presumably due to the MPIR
> > > > >> upgrade in 4.8.alpha0, seehttp://trac.sagemath.org/sage_trac/ticket/8664,
> > >
> > > > > Ah, I'm pretty sure yes.
> > >
> > > > >> different for each.
> > > > >> Use "--disable-static --enable-shared" to build just a DLL.
> > >
> > > This has always been the case for all windows systems , ie MSVC , cygwin , MSYS , and even interex.
> > > I don't think it's possible to make mpir.h independent of dll vs static builds, it basically has to be done in the makefile/build solution
> > >
> >
> >
> > "I can only comment on the MSVC Windows build, for which I believe
> > mpir.h is
> > identical DLL and static library builds. To double check this I have
> > just
> > built both and compared the two mpir.h files that were generated.
> > In fact mpir.h is now identical for win32 and x64 builds as well since
> > I
> > changed this recently to avoid any differences because an increasing
> > number
> > of people were trying to compile MPIR with the wrong version.
> > Brian "
> >
> > where in the makefile or spkg-install this might be fixed, please
> > comment on http://trac.sagemath.org/sage_trac/ticket/12115, where we
> > are tracking this, or here.
> >
> > Also, just FYI, just bypassing this doesn't fix all our Cygwin
> > problems - see the ticket above, again.
> >
> > Making all in yasm
> > make[4]: Entering directory `/home/Administrator/sage-4.8.alpha3/spkg/
> > build/mpir-2.1.3.p8/src/yasm'
> > gcc -std=gnu99 -I. -c -o genperf.o `test -f tools/genperf/genperf.c
> > || echo './'`tools/genperf/genperf.c
> > <snip>
> > gcc -std=gnu99 -I. -c -o re2c-parser.o `test -f tools/re2c/parser.c
> > || echo './'`tools/re2c/parser.c
> > Makefile:3665: recipe for target `re2c-parser.o' failed
> > make[4]: *** [re2c-parser.o] Error 1
> > make[4]: Leaving directory `/home/Administrator/sage-4.8.alpha3/spkg/
> > build/mpir-2.1.3.p8/src/yasm'
> > Makefile:772: recipe for target `all-recursive' failed
> > make[3]: *** [all-recursive] Error 1
> > make[3]: Leaving directory `/home/Administrator/sage-4.8.alpha3/spkg/
> > build/mpir-2.1.3.p8/src'
> > Makefile:603: recipe for target `all' failed
> > make[2]: *** [all] Error 2
> > make[2]: Leaving directory `/home/Administrator/sage-4.8.alpha3/spkg/
> > build/mpir-2.1.3.p8/src'
> > Error building MPIR.
> >
>
> This look like yasm is failing because your doing a parallel build , it's a known problem and has been reported at least a year ago , it only seems to effect cygwin ,
> a workaround is to build yasm first with just make and then build mpir with make -j
>
> Jason
>
>
it's been fixed it appears see
http://tortall.lighthouseapp.com/projects/78676/changesets/2bd66514b6b100887c19d8598da38347b3cff4
We should upgrade yasm in mpir to this for mpir-2.5 , which although delayed , I hope to get out next week, I've almost done all the tuning , just power7 to do ,
and some docs , and then our tests
Jason
Jason
> When I tracked down the yasm bug I made a trac ticket at
> http://trac.sagemath.org/sage_trac/ticket/11844
>
> On Saturday, December 3, 2011 11:54:03 PM UTC, jason wrote:
> > > This look like yasm is failing because your doing a parallel build ,
> >
> > it's a known problem and has been reported at least a year ago , it only
> > seems to effect cygwin ,
> >
> >
> >
> > http://tortall.lighthouseapp.com/projects/78676/changesets/2bd66514b6b100
> > 887c19d8598da38347b3cff4
I'll upgrade yasm to the new one today and put it in our svn , which you can
just copy , or use the new yasm youself and follow this change procedure in the
attached file , it's a diff but there are a few other things to do
Jason
Dima Pasechnik
Jason
Jason
I men the mpir svn server :)
Jason