Some good news.
If I hack together a tarball on my linux machine for mpir using make
dist then copy this to my MinGW32 machine, it builds no problem.
I still cannot figure out for the life of me what is different between
the two. According to svn, there is no difference!!
It seems we simply cannot build on MinGW32 from an svn checkout
without first doing autoreconf -i.
Fortunately, it is the tarball, not the svn checkout that we put on
the website for users. So I am calling it quits trying to solve this
problem.
>From now on, MinGW32 is only supported out-of-the-box when using a
tarball from the MPIR website, not when using an svn checkout.
Bill.
On 27 September 2012 16:43, Bill Hart <goodwillh...@googlemail.com> wrote:
> More bad news.
>
> The filename
> mpir-2.5.1/build.vc10/mpir-tests/fft.fft_ifft_mfa_truncate_sqrt2/fft.fft_ifft_mfa_truncate_sqrt2.vcxproj
> is apparently too long, so we cannot create a tarball of MPIR.
>
> Bill.
>
> On 27 September 2012 15:57, Bill Hart <goodwillh...@googlemail.com> wrote:
>> Obviously yasm files cannot be responsible for configure not filling
>> config.h correctly.
>>
>> And the autom4te.cache files are only to speed up autoreconf, not the
>> build system itself. (I tried committing these, but this didn't fix
>> the problem.)
>>
>> Running autoreconf -i followed by svn commit now yields nothing.
>>
>> So if no versioned files change between Windows and Linux and no
>> unversioned files are responsible for it not working, then what on
>> earth could be responsible?
>>
>> This is the most stupid bug I have ever encountered!
>>
>> Bill.
>>
>> On 27 September 2012 15:34, Bill Hart <goodwillh...@googlemail.com> wrote:
>>> Omigosh!!
>>>
>>> There was a single \n in the middle of a comment in the config.in
>>> generated on MinGW32 which prevented me from committing it to the
>>> repo. After fixing this I was able to commit the differences to the
>>> autotools files as generated by MinGW32's autoreconf 2.68 over the
>>> Linux autoreconf 2.68.
>>>
>>> The good news is this works on Linux. The bad news is it still doesn't
>>> work on MinGW.
>>>
>>> Clearly there are unversioned files (not committed to svn) which are
>>> required for correct operation on MinGW.
>>>
>>> make distclean
>>> svn status | grep ^?
>>>
>>> yields only:
>>>
>>> ? tests\fft\Makefile
>>>
>>> whereas
>>>
>>> autoreconf -i
>>> svn status | grep ^?
>>>
>>> yields:
>>>
>>> ? tests\fft\Makefile
>>> ? yasm\YASM-VERSION-FILE
>>> ? yasm\YASM-VERSION.h
>>> ? yasm\autom4te.cache
>>> ? autom4te.cache
>>>
>>> So, presumably one or more of those last four files needs to be under
>>> version control. Any guesses?
>>>
>>> Bill.
>>>
>>> On 27 September 2012 15:03, Bill Hart <goodwillh...@googlemail.com> wrote:
>>>> This did not work. The problem is I *cannot* commit the changes to svn
>>>> because of Windows line endings.
>>>>
>>>> Changing the svn:eol-style to native for those files does not fix the
>>>> problem (this only affects the line style used when the file is
>>>> checked out). Making this change to svn properties and then checking
>>>> out the repo again on MinGW32 doesn't fix the problem either.
>>>>
>>>> Also, it doesn't seem to be a case of the input files having incorrect
>>>> line endings either, as for example config.in is one of the files,
>>>> which as far as I know is not created by running configure or make.
>>>>
>>>> {pulls hair out}
>>>>
>>>> Bill.
>>>>
>>>> On 27 September 2012 14:27, Bill Hart <goodwillh...@googlemail.com> wrote:
>>>>> Some possible good news.
>>>>>
>>>>> The autoconf/autoreconf/automake versions I have on MinGW32 are
>>>>> *identical* to the ones we have on our linux development machine.
>>>>>
>>>>> This further confirms my suspicions that this is an extremely
>>>>> irritating autotools bug. There should be no difference whatsoever in
>>>>> the configure and Makefiles created by the precise same version of
>>>>> autotools between machines from the same input files. It is, after
>>>>> all, supposed to create a cross platform build system!
>>>>>
>>>>> But the possible good news is that maybe we can commit the changes
>>>>> made by autoreconf -i on MinGW32 and it will work everywhere, not just
>>>>> Linux and OSX. I am not confident it will work on older macs, because
>>>>> I've had that problem before. But these are pretty rare these days,
>>>>> and we might just get away with it.
>>>>>
>>>>> I will start experimenting with this to see what happens. Commit coming
>>>>> shortly.
>>>>>
>>>>> 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.
