On Sunday 13 February 2011 22:48:00 Cactus wrote: > On Feb 13, 10:37 pm, "jason" <ja...@njkfrudils.plus.com> wrote: > > Hi > > > > I think when using as a cross compile use > > CC=x86_64-w64-mingw32-gcc.exe > > and not > > CC=c:/path_etc/bin/x86_64-w64-mingw32-gcc.exe > > > > The configure for me works with space but the build fails with libtool , > > so nothing we can do :( > > On linux I imagine this would be the same but the binarys never have a > > space in them , I suppose I could hack up a linux example to test this > > but it's not worth the effort. One way I have used before to cope with > > spaces is install the program in directory with space as you want to , > > and then use a symbolic(or hard ) link from say > > c:\Program Files\dir with more spaces\msys\1.0 > > to > > c:\msys\1.0 > > > > I had a lot of scripts which accepted file names , and when I had to > > upgrade them to cope with file names with spaces it would of been so > > much work and testing , so what I did was to process any file names > > before the script by just created a symbolic link , that way I didn't > > have to change some very hairy scripts. > > > > Jason > > > > > > > > > > > > > > > > ----- Original Message ----- > > From: "jason" <ja...@njkfrudils.plus.com> > > To: <mpir-devel@googlegroups.com> > > Sent: Sunday, February 13, 2011 10:14 PM > > Subject: Re: [mpir-devel] Re: MinGW64 > > > > >I cant reproduce it yet , have you got the latest trunk? , because I've > > >fixed that "spurious error" yesterday , (wasn't really an error , you > > >can just ignore it , I was lazy) > > > > > > If you have the latest trunk then something else is afoot. > > > > > > Thanks > > > Jason > > > > > > ----- Original Message ----- > > > From: "jason" <ja...@njkfrudils.plus.com> > > > To: "mpir-devel" <mpir-devel@googlegroups.com> > > > Sent: Sunday, February 13, 2011 9:54 PM > > > Subject: [mpir-devel] Re: MinGW64 > > > > > > Hi > > > > > > Although autotools can mostly handle space , my little hack at the end > > > to get round as/asm issue cannot , I'll do a fix soonish > > > > > > Thanks > > > Jason > > > > > > On Feb 13, 7:01 pm, Cactus <rieman...@gmail.com> wrote: > > >> On Feb 13, 6:16 pm, Jason <ja...@njkfrudils.plus.com> wrote: > > >> > On Sunday 13 February 2011 17:03:40 Cactus wrote: > > >> > > On Feb 11, 4:34 pm, jason <ja...@njkfrudils.plus.com> wrote: > > >> > > > Hi , here is exactly how to do it , the installs seem consistent > > >> > > > now , > > >> > > > as I deleted the whole thing and reinstalled and it worked every > > >> > > > time > > >> > > > > > >> > > > The 64bit mingw comes configured as a cross compiler , which as > > >> > > > far as > > >> > > > we are concered just means that the gcc.exe etc are renamed to > > >> > > > x86_64- > > >> > > > w64-mingw32-gcc.exe so we have to pass these as params to > > >> > > > configure > > >> > > > > > >> > > > Make sure all your old broken msys/mingw are deleted or out of > > >> > > > the way > > >> > > > > > >> > > > Download MSYS-1.0.11.exe > > >> > > > fromhttp://sourceforge.net/projects/mingw/files/MSYS/BaseSystem/ > > >> > > > msys-cor e... > > >> > > > > > >> > > > Install it and select default options , a dos window will pop up > > >> > > > , answer "n" to the post install question (this stops it trying > > >> > > > to find > > >> > > > mingw which it seems to get very confused about) > > >> > > > > > >> > > > Download mingw-w64-1,0-bin_i686-mingw_20110207.zip > > >> > > > fromhttp://sourceforge.net/projects/mingw-w64/files/Toolchains%2 > > >> > > > 0targett i... > > >> > > > > > >> > > > unzip this file into the c:\msys\1.0\mingw directory > > >> > > > > > >> > > > Your ready to go , ie > > >> > > > > > >> > > > ./configure --enable-cxx CC=x86_64-w64-mingw32-gcc.exe > > >> > > > NM=x86_64-w64- > > >> > > > mingw32-nm.exe > > >> > > > AR=x86_64-w64-mingw32-ar.exe CXX=x86_64-w64-mingw32-g++.exe > > >> > > > > > >> > > > make and make check > > >> > > > The shared build fails make check with C++ but this is only > > >> > > > because autotools gets the wrong directory for the dll , this > > >> > > > was known before. > > >> > > > > > >> > > > A cross compiler is a pain , so to make it native we just rename > > >> > > > all > > >> > > > the exe's in the c:\msys\1.0\mingw\bin directory to give them > > >> > > > the usual names via > > >> > > > > > >> > > > for i in *.exe ; do mv $i $(echo $i | cut -d - -f 4) ; done > > >> > > > > > >> > > > which will do all but 1 file > > >> > > > > > >> > > > Then we can just use the usual > > >> > > > ./configure && make && make check > > >> > > > > > >> > > > I cant see any reason why later versions won't work, but as they > > >> > > > make > > >> > > > a lot changes per week , I think we should stick to the stable > > >> > > > ones. > > >> > > > > > >> > > > If someone would like to confirm that this works on their > > >> > > > machines > > >> > > > > > >> > > > Thanks > > >> > > > Jason > > >> > > > > > >> > > > On Feb 10, 11:42 pm, Jason <ja...@njkfrudils.plus.com> wrote: > > >> > > > > Hi > > >> > > > > > > >> > > > > MinGW64 installs seem to be problematic , and so far MPIR only > > >> > > > > works on > > >> > > > > my install and even then I had to rename some MinGW64 binarys > > >> > > > > etc , > > >> > > > > however the MinGW64 seem to of released a version-1.0 , so I > > >> > > > > will delete my current install and install exactly what they > > >> > > > > say on their > > >> > > > > page , and target that. > > >> > > > > > > >> > > > >http://mingw-w64.sourceforge.net/ > > >> > > > > > > >> > > > > Jason > > >> > > > > >> > > I am interested in what happens to the assembler code when MPIR is > > >> > > built with mingw64. > > >> > > > > >> > > Does the build pick up the *nix assembler code or the WIndows > > >> > > assembler code or is it only generic C > > >> > > > > >> > > I assume it can't use the *nix code because the calling > > >> > > conventions are wrong but I am interested if it picks up the > > >> > > Windows assembler. > > >> > > > >> > Yeah , it uses all the Windows assembler code from the relevant > > >> > directorys ie > > >> > core2,K8,k10,nehalem,atom,netburst , it has (and because of > > >> > autotools it must) > > >> > be the same as the linux layout and scope of choices. It will be > > >> > interesting > > >> > to see how the timings compare with MSVC , the assembler code is the > > >> > same only > > >> > the compiler for the C is different. > > >> > > > >> > > I guess I could try this but the last time I tried it didn't work > > >> > > because I have my *nix stuff installed in 'Program Files (x86)' (I > > >> > > don't want to use non-standard directories for executables as it > > >> > > messes up my security policy settings). > > >> > > > >> > I'm pretty sure you can install it anywhere , the latest versions > > >> > are much > > >> > better. You could install MSYS in another directory say > > >> > your_usual/MSYS_TEST > > >> > and just unzip the compiler into the same relative directory. To > > >> > uninstall it > > >> > , delete the compiler , then uninstall MSYS , and delete the empty > > >> > directorys. > > >> > Spaces in the path only matter (as far as I know) for the MPIR > > >> > directorys. > > >> > > > >> > Jason > > >> > > > >> > > Brian > > >> > > > >> > It uses the Windows assembler code > > >> > > >> Thanks Jason - that is really good news. > > >> > > >> I get a bit further this time but still cannot get it to build: > > >> > > >> Brian Gladman@MobileSlave /c/users/brian gladman/my documents/visual > > >> studio 2010 > > >> /projects/mpir > > >> $ ./configure --enable-cxx CC=c:/mingw64/bin/x86_64-w64-mingw32- > > >> gcc.exe NM=c:/m > > >> ingw64/bin/x86_64-w64-mingw32-nm.exe AR=c:/mingw64/bin/x86_64-w64- > > >> mingw32-ar.ex > > >> e CXX=c:/mingw64/bin/x86_64-w64-mingw32-g++.exe > > >> checking build system type... nehalem-w64-mingw32 > > >> checking host system type... nehalem-w64-mingw32 > > >> checking for a BSD-compatible install... /bin/install -c > > >> checking whether build environment is sane... yes > > >> checking for a thread-safe mkdir -p... /bin/mkdir -p > > >> checking for gawk... gawk > > >> checking whether make sets $(MAKE)... yes > > >> checking whether to enable maintainer-specific portions of > > >> Makefiles... no > > >> checking ABI=64 > > >> checking whether c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe is gcc... > > >> yes > > >> checking compiler c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe -O2 - > > >> m64 ... yes > > >> checking compiler c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe -O2 -m64 - > > >> march=cor > > >> e2... yes > > >> checking compiler c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe -O2 -m64 - > > >> march=core > > >> 2 -mtune=core2... yes > > >> checking for gcc... c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe > > >> checking whether the C compiler works... yes > > >> checking for C compiler default output file name... a.exe > > >> checking for suffix of executables... .exe > > >> checking whether we are cross compiling... no > > >> checking for suffix of object files... o > > >> checking whether we are using the GNU C compiler... yes > > >> checking whether c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe accepts - > > >> g... yes > > >> checking for c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe option to > > >> accept ISO C89. > > >> .. none needed > > >> checking how to run the C preprocessor... c:/mingw64/bin/x86_64-w64- > > >> mingw32-gcc. > > >> exe -E > > >> checking for grep that handles long lines and -e... /bin/grep > > >> checking for egrep... /bin/grep -E > > >> checking for ANSI C header files... yes > > >> checking for sys/types.h... yes > > >> checking for sys/stat.h... yes > > >> checking for stdlib.h... yes > > >> checking for string.h... yes > > >> checking for memory.h... yes > > >> checking for strings.h... yes > > >> checking for inttypes.h... yes > > >> checking for stdint.h... yes > > >> checking for unistd.h... yes > > >> checking minix/config.h usability... no > > >> checking minix/config.h presence... no > > >> checking for minix/config.h... no > > >> checking whether it is safe to define __EXTENSIONS__... yes > > >> checking for gcc... (cached) c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe > > >> checking whether we are using the GNU C compiler... (cached) yes > > >> checking whether c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe accepts - > > >> g... (cached > > >> ) yes > > >> checking for c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe option to > > >> accept ISO C89. > > >> .. (cached) none needed > > >> checking for c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe option to > > >> accept ISO C99. > > >> .. -std=gnu99 > > >> checking for c:/mingw64/bin/x86_64-w64-mingw32-gcc.exe -std=gnu99 > > >> option to acce > > >> pt ISO Standard C... (cached) -std=gnu99 > > >> checking how to run the C preprocessor... c:/mingw64/bin/x86_64-w64- > > >> mingw32-gcc. > > >> exe -E > > >> checking build system compiler c:/mingw64/bin/x86_64-w64-mingw32- > > >> gcc.exe -std=gn > > >> u99... yes > > >> checking for build system preprocessor... c:/mingw64/bin/x86_64-w64- > > >> mingw32-gcc. > > >> exe -std=gnu99 -E > > >> checking for build system executable suffix... .exe > > >> checking whether build system compiler is ANSI... yes > > >> checking for build system compiler math library... -lm > > >> checking whether we > > > > ... > > > > read more ยป > > I did not have the recent SVN changes but it still fails now that I > have updated from SVN > > Brian
Hi Thanks , so where does it fail now? 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-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.
