threads / discuss / 32671

tar-tree.c dereferencing pointer to incomplete type

Subject: tar-tree.c dereferencing pointer to incomplete type

## tl;dr

5 messages between Jan 19, 2013 and Jan 19, 2013.

replies: 4people: 3as markdown or json

白い熊· Jan 19, 2013, 13:31 UTC · lore
Hello:

I'm building v 1.8.1.1 on Android. The build chokes on the builtins phase on tar-tree.c with:

    CC builtin/tar-tree.o
builtin/tar-tree.c: In function 'cmd_get_tar_commit_id':
builtin/tar-tree.c:93:12: error: dereferencing pointer to incomplete type
make: *** [builtin/tar-tree.o] Error 1
The line that's causing this in tar-tree.c is:
if (header->typeflag[0] != 'g')
from
int cmd_get_tar_commit_id(int argc, const char **argv, const char *prefix)
{
	char buffer[HEADERSIZE];
	struct ustar_header *header = (struct ustar_header *)buffer;
	char *content = buffer + RECORDSIZE;
	ssize_t n;
	if (argc != 1)
		usage(builtin_get_tar_commit_id_usage);
	n = read_in_full(0, buffer, HEADERSIZE);
	if (n < HEADERSIZE)
		die("git get-tar-commit-id: read error");
	if (header->typeflag[0] != 'g')
		return 1;
	if (memcmp(content, "52 comment=", 11))
		return 1;
	n = write_in_full(1, content + 11, 41);
	if (n < 41)
		die_errno("git get-tar-commit-id: write error");
	return 0;
}
But why?
What's messed up with my setup.

I can compile no probs on other machines. I'm trying to get my head round this, but don't see the problem?

-- 
白い熊
Duy Nguyen· Jan 19, 2013, 13:37 UTC · re: 白い熊 · lore

Re: tar-tree.c dereferencing pointer to incomplete type

On Sat, Jan 19, 2013 at 8:31 PM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
Show 13 quoted lines
> Hello:
>
> I'm building v 1.8.1.1 on Android. The build chokes on the builtins
> phase on tar-tree.c with:
>
>     CC builtin/tar-tree.o
> builtin/tar-tree.c: In function 'cmd_get_tar_commit_id':
> builtin/tar-tree.c:93:12: error: dereferencing pointer to incomplete type
> make: *** [builtin/tar-tree.o] Error 1
>
> The line that's causing this in tar-tree.c is:
>
> if (header->typeflag[0] != 'g')

There is another tar.h somewhere in your system? Stopping the compilation after proprocessing should show if it includes the correct tar.h.

-- 
Duy
白い熊· Jan 19, 2013, 14:26 UTC · re: Duy Nguyen · lore

Re: tar-tree.c dereferencing pointer to incomplete type

On Sat, Jan 19, 2013 at 5:37 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> There is another tar.h somewhere in your system? Stopping the
> compilation after proprocessing should show if it includes the correct
> tar.h.
Thank you, this must've been it, as it was finding tar.h from glibc.

Moved it and compiles fine. In fact I moved it back now, so it should be finding it again and it still builds fine, no trace of the prior error. I'm dumbfounded! But at least it compiles...

-- 
白い熊
白い熊· Jan 19, 2013, 14:37 UTC · re: 白い熊 · lore

Re: tar-tree.c dereferencing pointer to incomplete type

On Sat, Jan 19, 2013 at 6:26 PM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
Show 5 quoted lines
> Thank you, this must've been it, as it was finding tar.h from glibc.
>
> Moved it and compiles fine. In fact I moved it back now, so it should
> be finding it again and it still builds fine, no trace of the prior
> error. I'm dumbfounded! But at least it compiles...

OK, figured it out. It was indeed the wrong tar.h, the one that was making it bomb was the kernel headers tar.h from the Android source. That explains it quite well.

All's good now. Thank you :@)
-- 
白い熊
Jonathan Nieder· Jan 19, 2013, 21:28 UTC · re: 白い熊 · lore

Re: tar-tree.c dereferencing pointer to incomplete type

白い熊 wrote:
> On Sat, Jan 19, 2013 at 6:26 PM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
Show 7 quoted lines
>> Moved it and compiles fine. In fact I moved it back now, so it should
>> be finding it again and it still builds fine, no trace of the prior
>> error. I'm dumbfounded! But at least it compiles...
>
> OK, figured it out. It was indeed the wrong tar.h, the one that was
> making it bomb was the kernel headers tar.h from the Android source.
> That explains it quite well.

Hm. Is there anything to do to make our headers specified with -I take precedence over unrelated system headers when processing '#include "foo.h"' directives?

Thanks, Jonathan

← back to recent threads