Re: [msysGit] [PATCH 07/14] Fix BASIC_LDFLAGS and COMPAT_CFLAGS for 64bit MinGW-w64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ray,

On Fri, 10 Oct 2014, Ray Donnelly wrote:

> On Thu, Oct 9, 2014 at 8:47 PM, Johannes Schindelin <
> Johannes.Schindelin@xxxxxx> wrote:
> >
> > On Thu, 9 Oct 2014, Ray Donnelly wrote:
> >
> >> On Thu, Oct 9, 2014 at 8:22 PM, Johannes Schindelin
> >> <Johannes.Schindelin@xxxxxx> 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]