git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: "Torsten Bögershausen" <tboegi@web.de>,
	"Vicent Martí" <tanoku@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Oct 2013, #07; Mon, 28)
Date: Wed, 30 Oct 2013 19:11:58 +0000	[thread overview]
Message-ID: <527159FE.6040706@ramsay1.demon.co.uk> (raw)
In-Reply-To: <5271443D.3070402@web.de>

On 30/10/13 17:39, Torsten Bögershausen wrote:
> On 2013-10-30 18.14, Torsten Bögershausen wrote:
>> On 2013-10-30 18.01, Vicent Martí wrote:
>>> On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>>> There is a name clash under cygwin 1.7 (1.5 is OK)
>>>> The following "first aid hot fix" works for me:
>>>> /Torsten
>>>
>>> If Cygwin declares its own bswap_64, wouldn't it be better to use it
>>> instead of overwriting it with our own?
>> Yes,
>> this will be part of a longer patch.
>> I found that some systems have something like this:
>>
>> #define htobe64(x) bswap_64(x)
>> And bswap_64 is a function, so we can not detect it by "asking"
>> #ifdef bswap_64
>> ..
>> #endif
>>
>>
>> But we can use
>> #ifdef htobe64
>> ...
>> #endif
>> and this will be part of a bigger patch.
>>
>> And, in general, we should avoid to introduce functions which may have a
>> name clash.
>> Using the git_ prefix for function names is a good practice.
>> So in order to unbrake the compilation error under cygwin 17,
>> the "hotfix" can be used.
>> /Torsten
> I just realized that there seem to problems to compile pu under msysgit.
> More investigation needed here.

... I noticed this too, and my patch is given below (I have another
patch for mingw which fixes some printf format warnings too) ...

However, you would not be surprised to hear that this breaks on msvc
too, so I too was planning a larger re-write ... :-D

ATB,
Ramsay Jones

-- >8 --
Subject: [PATCH] compat/bswap.h: Fix failure to determine endianness on MinGW

Since commit 452e0f20 ("compat: add endianness helpers", 24-10-2013)
added the 'ntohll' and 'htonll' helpers, the MinGW build has failed
like so:

    GIT_VERSION = 1.8.4.1.804.g1f3748b
        * new build flags
        CC credential-store.o
    In file included from git-compat-util.h:305,
                     from cache.h:4,
                     from credential-store.c:1:
    compat/bswap.h:56:4: error: #error "Cannot determine endianness"
    make: *** [credential-store.o] Error 1

The #error is triggered because the 'endian macros' BYTE_ORDER,
LITTLE_ENDIAN and BIG_ENDIAN not being defined. On MinGW, these macros
are defined in the <sys/param.h> header file. In order to suppress the
error, set the build variable NEEDS_SYS_PARAM_H, which will cause the
"git-compat-util.h" header file to include <sys/param.h>.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
 config.mak.uname | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config.mak.uname b/config.mak.uname
index 82d549e..c03ea1e 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -469,6 +469,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
 	pathsep = ;
 	NO_PREAD = YesPlease
 	NEEDS_CRYPTO_WITH_SSL = YesPlease
+	NEEDS_SYS_PARAM_H = YesPlease
 	NO_LIBGEN_H = YesPlease
 	NO_POLL = YesPlease
 	NO_SYMLINK_HEAD = YesPlease
-- 
1.8.4

  reply	other threads:[~2013-10-30 19:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-28 19:28 What's cooking in git.git (Oct 2013, #07; Mon, 28) Junio C Hamano
2013-10-28 21:58 ` Thomas Rast
2013-10-30 16:51 ` Torsten Bögershausen
2013-10-30 17:01   ` Vicent Martí
2013-10-30 17:14     ` Torsten Bögershausen
2013-10-30 17:39       ` Torsten Bögershausen
2013-10-30 19:11         ` Ramsay Jones [this message]
2013-10-30 19:06       ` Ramsay Jones
2013-10-30 20:30         ` Torsten Bögershausen
2013-10-30 21:07           ` Ramsay Jones
2013-10-31 13:24             ` htonll, ntohll Torsten Bögershausen
2013-11-05  0:00               ` Ramsay Jones
2013-11-06 15:58                 ` Torsten Bögershausen
2013-11-12 14:44                 ` Jakub Narębski
2013-11-13 12:20                 ` Andreas Ericsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527159FE.6040706@ramsay1.demon.co.uk \
    --to=ramsay@ramsay1.demon.co.uk \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tanoku@gmail.com \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).