So if I check non-versioned files after make distclean when checked out directly from repo, I just get:
? tests\fft\Makefile But if I first do autoreconf -i, then I get ? tests\fft\Makefile ? yasm\YASM-VERSION-FILE ? yasm\YASM-VERSION.h ? yasm\autom4te.cache ? autom4te.cache So it looks like the first is not cleaned up when it should be, which is a separate issue. And the last file must be the one responsible for fixing the issue we are having. Anyone know what this file is for? Should we just commit it to the repo? Bill. On 26 September 2012 18:24, Bill Hart <goodwillh...@googlemail.com> wrote: > No, the problem comes back if I check out directly from the repo. > > Clearly autoreconf -i is altering some non-versioned files which are > required for it to build on MinGW32. And those files must be listed > below. > > We are closer to solving this mystery though! > > Bill. > > On 26 September 2012 18:07, Bill Hart <goodwillh...@googlemail.com> wrote: >> And much to my surprise, running autoreconf -i actually fixes the >> problem with the latest revision. >> >> I've committed the changes to the repo (the only file that changed was >> configure). >> >> However, I now note that make distclean does not clean the following files: >> >> ? autom4te.cache >> ? yasm/autom4te.cache >> ? tests/fft/Makefile >> ? mpn/preinv_divrem_1.c >> >> So that has to be added to the list of things to fix. I'm a bit >> surprised autotools doesn't figure these out for itself. >> >> I hope that those cache files are not the reason for it working after >> autoreconf -i. I'll have to check into that. >> >> Bill. >> >> On 26 September 2012 17:35, Bill Hart <goodwillh...@googlemail.com> wrote: >>> On 26 September 2012 17:34, Bill Hart <goodwillh...@googlemail.com> wrote: >>>> No, that didn't work. As usual, config.h is unpopulated. However, >>>> oddly enough, the error message I got was the same as what Pavel got >>>> before autoreconf. >>>> >>>> So we've confirmed that revision 3947 from trunk works with these >>> >>> Sorry, I mean 3778 works with those steps. >>> >>>> steps and the latest revision does not work without them. >>>> >>>> I will try replicating Pavel's steps exactly (which shouldn't be >>>> needed) to see what happens. >>>> >>>> Bill. >>>> >>>> On 26 September 2012 17:23, Bill Hart <goodwillh...@googlemail.com> wrote: >>>>> Thanks for giving this a try. >>>>> >>>>> Two things you may have to do: >>>>> >>>>> * turn off your antivirus, especially if configure causes a problem >>>>> with the generated program a.exe >>>>> * run mingw shell as administrator >>>>> >>>>> I also had exactly the same problem as you. I think it is due to >>>>> problems with config.h not being populated. >>>>> >>>>> However, what you subsequently wrote gave me an idea. I was not aware >>>>> that autoreconf actually worked with mpir. The reason is that it runs >>>>> libtoolize, which replaces the libtool with a broken one (this has >>>>> always been a problem with mpir). So I decided to run the other >>>>> programs that autoreconf runs, and I noticed that aclocal gives us a >>>>> diff. >>>>> >>>>> Just trying that now with the latest svn revision. >>>>> >>>>> Bill. >>>>> >>>>> On 26 September 2012 03:54, Pavel Holoborodko <pa...@holoborodko.com> >>>>> wrote: >>>>>> My environment: >>>>>> 1. Windows 7 Ultimate x64. >>>>>> 2. Latest MinGW32 with gcc 4.7.0 >>>>>> (installed from official site: >>>>>> http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/mingw-get-inst-20120426.exe/download) >>>>>> >>>>>> I've downloaded 3778 revision from the SVN (tagged as MPIR 2.5) >>>>>> >>>>>> ./configure --prefix=/mingw --host=i686-pc-mingw32 --enable-gmpcompat >>>>>> make clean >>>>>> make >>>>>> >>>>>> .... >>>>>> libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. >>>>>> -D__GMP_WITHIN_GMP -I.. -DOPERATION_divisible_p -m32 -O2 >>>>>> -fomit-frame-pointer -mtune=pentiumpro -march=pentiumpro -c >>>>>> divisible_p.c -o >>>>>> divisible_p.o >>>>>> divisible_p.c: In function '__gmpn_divisible_p': >>>>>> divisible_p.c:76:3: error: 'TMP_DECL' undeclared (first use in this >>>>>> function) >>>>>> divisible_p.c:76:3: note: each undeclared identifier is reported only >>>>>> once >>>>>> for each function it appears in >>>>>> divisible_p.c:141:3: error: 'TMP_MARK' undeclared (first use in this >>>>>> function) >>>>>> divisible_p.c:143:3: warning: implicit declaration of function >>>>>> 'TMP_ALLOC' >>>>>> [-Wimplicit-function-declaration] >>>>>> divisible_p.c:154:4: error: 'TMP_FREE' undeclared (first use in this >>>>>> function) >>>>>> make[2]: *** [divisible_p.lo] Error 1 >>>>>> make[2]: Leaving directory `/u/Development/trunk/libs/mp-mingw/mpir/mpn' >>>>>> make[1]: *** [all-recursive] Error 1 >>>>>> make[1]: Leaving directory `/u/Development/trunk/libs/mp-mingw/mpir' >>>>>> make: *** [all] Error 2 >>>>>> >>>>>> Generated configure.h is in attachment. >>>>>> >>>>>> Let me know how I can help you in fixing this problem. >>>>>> >>>>>> Pavel Holoborodko >>>>>> -- >>>>>> Multiprecision Computing Toolbox for MATLAB >>>>>> http://www.advanpix.com >>>>>> >>>>>> >>>>>> On Wed, Sep 26, 2012 at 1:52 AM, Bill Hart <goodwillh...@googlemail.com> >>>>>> wrote: >>>>>>> >>>>>>> On 25 September 2012 17:02, Bill Hart <goodwillh...@googlemail.com> >>>>>>> wrote: >>>>>>> > I would *really* appreciate some help with the Mingw32 issue. What we >>>>>>> > need to do is bisect the repo (svn trunk) and rebuild mpir until we >>>>>>> > find out which commit caused mingw32 to stop working. It might only be >>>>>>> > necessary to run configure and check to see if config.h has been >>>>>>> > populated correctly with all the HAVE_NATIVE flags, which would save a >>>>>>> > lot of time. >>>>>>> >>>>>>> Below is the relevant information from a previous post by Jason which >>>>>>> explains what goes wrong. It has always been a problem on MinGW64, but >>>>>>> seems to be a problem now on MinGW32. >>>>>>> >>>>>>> At any rate, all that would be required is to build mpir from svn >>>>>>> trunk starting with the revision corresponding to mpir-2.5.1 (where it >>>>>>> presumably last worked on MinGW32), i.e. revision 3850 and find which >>>>>>> commit before revision 3949 causes the config.h file to not be >>>>>>> properly populated as explained by Jason below. >>>>>>> >>>>>>> Any volunteers? >>>>>>> >>>>>>> --------------- >>>>>>> >>>>>>> I figured out what going on here , basically configure is failing to >>>>>>> populate config.h with the required >>>>>>> #define HAVE_NATIVE_mpn_addmul_2 1 >>>>>>> and all the others , it has always done this on mingw64 but because of >>>>>>> the way the C file redc_2 uses addmul_2 it now causes a problem.A >>>>>>> quick fix is to delete the lines in the mpn/generic/redc_2.c file >>>>>>> where it trys to redefine addmul_2 >>>>>>> >>>>>>> I don't know why configure fails to populate config.h , it manages to >>>>>>> do the sym links >>>>>>> >>>>>>> ---------------- >>>>>>> >>>>>>> Bill. >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups >>>>>>> "mpir-devel" group. >>>>>>> To post to this group, send email to mpir-devel@googlegroups.com. >>>>>>> To unsubscribe from this group, send email to >>>>>>> mpir-devel+unsubscr...@googlegroups.com. >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/mpir-devel?hl=en. >>>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups >>>>>> "mpir-devel" group. >>>>>> To post to this group, send email to mpir-devel@googlegroups.com. >>>>>> To unsubscribe from this group, send email to >>>>>> mpir-devel+unsubscr...@googlegroups.com. >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
