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

2014-10-14 Thread Marat Radchenko
On Thu, Oct 09, 2014 at 09:22:19PM +0200, Johannes Schindelin wrote:
 Hi,
 
 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.

According to [1], it is by design. For now, I suggest using separate
gcc binaries for 32/64, without messing with -m32. Of course we can
fallback to `./configure` that will determine bitness by compiling something.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52096#c1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2014-10-11 Thread Johannes Schindelin
Hi Ray,

On Fri, 10 Oct 2014, Ray Donnelly wrote:

 what's the difference between https://github.com/msysgit/git and
 https://github.com/git-for-windows/git ? I noticed that your fork is
 forked from msysgit, not git-for-windows?

I am glad you asked!

Git for Windows was developed using the development environment called
msysGit ever since 2007. Unfortunately the name caused a *real* lot of
confusion, not only because some people wondered what the heck MSys is,
but those who did not wonder mistook it for a *different* version of Git
for Windows.

Apart from the name, msysGit also has the shortcoming of abusing Git to
deploy binaries. In other words, msysGit itself is a Git-managed project
that delivers the complete development environment. Upgrading individual
components is unnecessarily hard, but msysGit's way was necessary because
there was no nice package manager for MinGW/MSys yet.

Things have changed in the meantime, and pushed forward by Thomas Braun
and Sebastian Schuberth, we now have a light-weight Git for Windows SDK –
which is essentially a standard MinGW/MSys system managed through the
package manager mingw-get. The only two add-ons we have is a nicer
installer (that Sebastian offered to MinGW but they declined) and the
addition of our own mingw-get'able packages (such as openssl, libpcre, and
git itself).

Needless to say, I am a big fan of that new strategy. This is why we
decided to just phase out the name msysGit (as well as the GitHub org of
the same name) and work on Git for Windows (with the corresponding GitHub
org, and using the name Git for Windows for the installer aimed at
end-users and Git for Windows SDK for the development environment
targeting Git for Windows developers).

I also added this writeup to the FAQ on the msysGit wiki:
https://github.com/msysgit/msysgit/wiki/Relationship-to-Git-for-Windows

Ciao,
Johannes

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

2014-10-11 Thread Johannes Schindelin
Hi,

On Fri, 10 Oct 2014, Johannes Schindelin wrote:

 On Fri, 10 Oct 2014, Johannes Schindelin wrote:
 
  With this [mingw-w64] 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).
 [...]
 
 So I fear we have still a ways to go before Git works as a 64-bit Windows
 binary...

It seems to be not *all* that bad: only t3900, t3901, t4041, t4205, t4210,
t5100, t6006 and t7102 display test failures.

Ciao,
Dscho

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

2014-10-10 Thread Johannes Schindelin
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 way 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

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

2014-10-10 Thread Johannes Schindelin
Hi,

On Fri, 10 Oct 2014, Johannes Schindelin wrote:

 With this [mingw-w64] 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).

And it stopped at t3900-i18n-commit.txt:

not ok 15 - ISO8859-1 should be shown in UTF-8 now
not ok 16 - eucJP should be shown in UTF-8 now
not ok 17 - ISO-2022-JP should be shown in UTF-8 now
not ok 23 - ISO8859-1 should be shown in UTF-8 now
not ok 24 - eucJP should be shown in UTF-8 now
not ok 25 - ISO-2022-JP should be shown in UTF-8 now
not ok 27 - ISO-2022-JP should be shown in eucJP now
not ok 28 - eucJP should be shown in ISO-2022-JP now

Inspecting the test case 15 above, it appears as if ISO-8859-1 was still
shown as ISO-8859-1 instead of UTF-8:

$ hexdump.exe /git/t/t3900/1-UTF-8.txt trash
directory.t3900-i18n-commit/current
 /git/t/t3900/1-UTF-8.txt 
  c3 84 c3 8b c3 91 c3 8f  c3 96 0a 0a c3 81 62 c3
0010  a7 64 c3 a8 66 67 0a
 trash directory.t3900-i18n-commit/current 
  c4 cb d1 cf d6 0a 0a c1  62 e7 64 e8 66 67 0a

So I fear we have still a ways to go before Git works as a 64-bit Windows
binary...

Ciao,
Johannes

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

2014-10-09 Thread Johannes Schindelin
Hi,

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.

Ciao,
Johannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2014-10-09 Thread Ray Donnelly
On Thu, Oct 9, 2014 at 8:22 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
 Hi,

 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?


 Ciao,
 Johannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2014-10-09 Thread Johannes Schindelin
Hi Ray,

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?

Certainly:

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-win32/sjlj/

(rev1, not rev0)

Ciao,
Johannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html