Hi Ray, On Fri, 10 Oct 2014, Ray Donnelly wrote:
> On Thu, Oct 9, 2014 at 8:47 PM, Johannes Schindelin < > johannes.schinde...@gmx.de> wrote: > > > > On Thu, 9 Oct 2014, Ray Donnelly wrote: > > > >> On Thu, Oct 9, 2014 at 8:22 PM, Johannes Schindelin > >> <johannes.schinde...@gmx.de> wrote: > >> > > >> > On Wed, 8 Oct 2014, Marat Radchenko wrote: > >> > > >> >> +CC_MACH := $(shell sh -c '$(CC) -dumpmachine 2>/dev/null || echo > not') > >> > > >> > There is a rather huge problem with that. The latest mingw-w64 > >> > release, 4.9.1, does not do what you expect here: while > >> > '.../mingw32/bin/gcc -m32 -o 32.exe test.c' and > >> > '.../mingw32/bin/gcc -m64 -o 64.exe test.c' work fine, producing > >> > i686 and x86_64 executables respectively, '.../mingw32/bin/gcc > >> > -dumpmachine' prints i686-w64-mingw32 *always*, even when > >> > specifying the -m64 option. > >> > > >> > So unfortunately, the test introduced by this patch (intended to > >> > figure out whether the build targets i686, and skip a compiler and > >> > a linker option otherwise) is incorrect. > >> > >> Which release are you talking about? Can you point me to the tarball > >> please? > > > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-win32/sjlj/ > > > > (rev1, not rev0) > > I guess I can add passing in CFLAGS also to try to catch that case. Well, my tests say that the CFLAGS do *not* change the behavior of -dumpmachine. IOW `i686-w64-mingw32-gcc -m64 -dumpmachine` *still* spits out i686-w64-mingw32. Even if the -m64 flag would cause the compiler to generate 64-bit binaries. > I've added support to build using your branch to MSYS2's MINGW-packages > git-git package in case anyone wants to help out: > > https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-git-git Interesting. With Git for Windows, we aim to become waaaaay more standards-compliant by providing Git as a regular mingw-get'able package. To this end, we use mgwport recipes to build the required packages. It looks as if the PKGBUILD system is similar, but *just* incompatible enough with mgwport to prevent code sharing. Is this fixable? > Change _based_on_dscho_w64_msysgit=no to =yes. Note also that some more > patches are needed before we can build, and I think more are needed. > Using plain msysGit (I.e. =no) and 15 patches we are able to build a > somewhat functional git. So here is my plan, please let me know whether you think we can compromise on a strategy that benefits both of us: Since I want mingw-get'able packages – also for 64-bit – I would like to keep the CPU architecture dependent parts as contained as possible and use only one package system for both. Likewise, I would really prefer to have a single development environment for both architectures, and the Git for Windows SDK is really coming along nicely, thanks to the tremendous efforts put in by Thomas Braun and Sebastian Schuberth. I am planning, therefore, to provide the MinGW-w64 compiler as an add-on package that needs to be installed in order to build 64-bit stuff. At this stage, it is actually *more* than a plan: I already have a package to install 7za – required to unpack MinGW-w64 pre-built packages – and the script to package mingw-w64 is in the process of being fleshed out. With this compiler, and the 'w64' branch from https://github.com/dscho/git – intended to be merged into https://github.com/git-for-windows/git – the following command-line produces 64-bit Git: PATH=/path/to/unpacked/mingw-w64/mingw64/bin/:$PATH \ make \ CROSS_COMPILE=x86_64-w64-mingw32- CC='$(CROSS_COMPILE)gcc' \ AR=ar RC=windres \ NO_ICONV=1 NO_OPENSSL=1 NO_CURL=1 NEEDS_LIBICONV= USE_LIBPCRE= The test suite passes so far (still running, at the time of writing it is going through t3404). Ciao, Johannes
