Looks like it may be an autotools problem in that it's not setting the path to the shared library properly . There are later autotools available which may fix this.
mpir-2.1 uses (from boxen) libtool 1.5.26 autoconf 2.61 automake 1.10.1 mpir-2.2 uses (from eno) libtool 2.2.6b autoconf 2.65 automake 1.11.1 latest versions are libtool 2.4 autoconf 2.68 automake 1.11.1 This may also fix the MinGW64 c++ shared library make check path issue. I'll try the latest autotools for MPIR v2.3 and see if it fixes/breaks anything. Jason On Friday 19 November 2010 08:57:53 Jason wrote: > On Friday 19 November 2010 01:10:47 Jeff Gilchrist wrote: > > On Thu, Nov 18, 2010 at 5:29 PM, Jason <ja...@njkfrudils.plus.com> wrote: > > > I'm assuming case 3 is on the same machine as the failed case ? > > > > Yes, they are the same machine. > > > > > Did the previous mpir v2.1 fail with the same options ? > > > > I just checked an v2.1.3 also fails with the same options enabled > > > > > Can you try it without the --enable-assert to see if it's some old > > > assertion getting in the way , and also perhaps without --enable-cxx to > > > see if it's the c++ being a problem. > > > > The machine works fine with just --enable-cxx, I also tried with just > > --enable-fat and I get the failure so it seems to be a fat thing. > > > > > Do you have another compiler on that system to try ? , in case it is > > > that particular compiler setup. > > > > The only other compiler on the system is pathscale which is a variant > > of gcc and gives the same error. > > > > > You could try replacing mpn/x86_64/fat/fat_entry.asm with the version > > > from mpir v2.1 , as the file has changed , but only a little bit ! > > > > Since the compile error is happening with 2.1, I figure there isn't > > much point in trying this. > > > > Jeff. > > Thanks , I have no idea what it is , the only thing I can suggest for the > moment is to try a build for static only , and then in a clean dir a shared > build only. I'm not sure what it will tell us !!! > Another possible thing to try is to make mpir on the broken machine as far > as it will go , tar it up , and transfer to another machine and try make , > if the time stamps are OK , it should proceed from where the broken > machine left off. If we are lucky the build will complete , it may not for > many reasons , but it may??? tell us some thing useful , I'm clutching at > straws here... > > Thanks > Jason -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@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.
