Bug#886815: r-cran-git2r uses private header files of libgit2 (Was: Help with libgit2 needed to strip code copy from r-cran-git2r)
Hello Andreas:
On 11/01/18 15:11, Andreas Tille wrote:
> Hi again,
>
> On Thu, Jan 11, 2018 at 08:34:09AM +0100, Andreas Tille wrote:
>>> # Add include paths for git2r
>>> -CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
>>> ${CPPFLAGS}"
>>> -+CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"
>>> ++CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"
>>
>> ...
>> gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -idirafter /usr/include/git2 -DGIT_ARCH_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DGIT_OPENSSL -DLIBGIT2_NO_FEATURES_H -DGIT_SHA1_OPENSSL -DGIT_SSH -DGIT_CURL -DGIT_USE_STAT_MTIM -DGIT_USE_NSEC -DHAVE_FUTIMENS -DHAVE_QSORT_R -fpic -g -O2 -fdebug-prefix-map=/build/r-base-3.4.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c git2r_branch.c -o git2r_branch.o
>> git2r_branch.c: In function 'git2r_branch_upstream_canonical_name':
>> git2r_branch.c:407:19: error: 'GIT_BUF_INIT' undeclared (first use in this function); did you mean 'GIT_REF_OID'?
>> git_buf buf = GIT_BUF_INIT;
>> ^~~~~~~~~~~~
>> GIT_REF_OID
>> git2r_branch.c:407:19: note: each undeclared identifier is reported only once for each function it appears in
>> git2r_branch.c:427:11: warning: implicit declaration of function 'git_buf_join3'; did you mean 'git_buf_set'? [-Wimplicit-function-declaration]
>> err = git_buf_join3(
>> ^~~~~~~~~~~~~
>> git_buf_set
>> /usr/lib/R/etc/Makeconf:159: recipe for target 'git2r_branch.o' failed
>>
>>
>> This is in
>>
>> /usr/include/git2/buffer.h:#define GIT_BUF_INIT_CONST(STR,LEN) { (char *)(STR), 0, (size_t)(LEN) }
>>
>> but it seems a different buffer.h is used.
>
> I dived a bit deeper into this and found this other buffer.h: It is a
> private header from libgit2/src/ and other headers from there are needed
> as well like common.h, cc_compat.h, thread-utils.h and possibly other
> header files.
>
> That's ... uhmmmm, no idea how to call this. What would you suggest:
> Live with the nasty code copy and just add it to debian/copyright or
> hack around all those usage of private header files. I've pushed some
> changes to Git[1] which keeps some (not all needed - for instance
> thread-utils.h is missing) but if there is no better idea how to deal
> with this I think I have better things to spent my time on than getting
> rid of a code copy you can not really cleanly get rid of.
>
I agree with your analysis, the mess of headers that libgit2 is using
IMHO could make the solution (cherry pick only some parts of libgit2)
worse than maintaining the embedded copy.
--
Jose Luis Rivero <jrivero@osrfoundation.org>
Reply to: