Curiosity drove me to give it a look. From what I understand: libgit2 seems
to be multiplatform and for some of the platforms (this time Windows) they
are shipping files with the same names that those that we can find in
/usr/include, in this case inttypes.h. You have include in your patch to
use the system version of libgit2 an -I/usr/include/git2 which is making
the compilation to use the inttypes.h from libgit2 (the windows copy)
instead of the one in /usr/include (which is evaluated the last by the
compiler).
Something like this patch should work, although I did not test it:
"""
diff --git a/debian/patches/use_debian_packaged_libgit2.patch
b/debian/patches/use_debian_packaged_libgit2.patch
index ab603cd..c716773 100644
--- a/debian/patches/use_debian_packaged_libgit2.patch
+++ b/debian/patches/use_debian_packaged_libgit2.patch
@@ -87,7 +87,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100
if test "x${have_ssh2}" = xyes; then
- LIBSSH2_CFLAGS="-Ilibgit2/deps/libssh2/include"
- LIBSSH2_LIBS="-Llibgit2/deps/libssh2/lib -lssh2"
-+ LIBSSH2_CFLAGS="-idirafter /usr/include/git2"
++ LIBSSH2_CFLAGS="-I/usr/include/git2"
+ LIBSSH2_LIBS="-lgit2 -lssh2"
fi
fi
@@ -97,7 +97,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100
# Add include paths for git2r
-CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
${CPPFLAGS}"
-+CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"
++CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"
# Add definitions
CPPFLAGS="${CPPFLAGS} -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DGIT_OPENSSL
-DLIBGIT2_NO_FEATURES_H"
"""
If use the "-idirafter" option the libgit2 headers are evaluated in the
last position when invoking the compiler, so the linux system inttypes.h go
first:
https://gcc.gnu.org/onlinedocs/cpp/Invocation.html#Invocation
On Thu, Jan 11, 2018 at 12:15 AM, Philip Rinn <ri...@inventati.org> wrote:
> Hi,
>
> I looked into this as well this evening and didn't really understand what
> they are
> doing. Did you ask the upstream authors why they didn't just depend on
> libgit2 as
> they did for libssh2, OpenSSL, ...? It's probably easier to understand the
> problem
> with their help. [If you don't want to do that I can do...]
>
> Best,
>
> Philip
>
>
