Looks like three separate portability bugs; thanks for doing the make -k, this lets us deal with them all at the same time!

(In reply to comment #0)
> next build issue...here is the complete output on stderr when running make -k:
> 
> gibber-resolver.c: In function 'gibber_resolver_res_query_to_list':
> gibber-resolver.c:667: error: 'HEADER' undeclared (first use in this function)
> gibber-resolver.c:667: error: (Each undeclared identifier is reported only once
> gibber-resolver.c:667: error: for each function it appears in.)
> gibber-resolver.c:669: error: 'head' undeclared (first use in this function)
> gibber-resolver.c:669: error: parse error before ')' token
> gibber-resolver.c:678: error: 'QFIXEDSZ' undeclared (first use in this
> function)
> gibber-resolver.c:692: error: 'T_SRV' undeclared (first use in this function)
> gibber-resolver.c:692: error: 'C_IN' undeclared (first use in this function)

Jack, could you look at your standard library headers - is there a macro we can use to obtain these on Darwin? On Linux you need either <arpa/nameser_compat.h>, or <arpa/nameser.h> with BIND_4_COMPAT defined (which that header does automatically). Perhaps defining BIND_4_COMPAT on Darwin would work?

Sjoerd, do you have any idea about the portability of those headers?

> gibber-resolver.c: In function 'gibber_resolver_gai_error_to_g_error':
> gibber-resolver.c:738: error: 'EAI_OVERFLOW' undeclared (first use in this
> function)

That error code might be Linux-specific; we could do an autoconf test for it?

> util.c: In function 'gabble_generate_id':
> util.c:82: error: storage size of 'uu' isn't known
> util.c:86: warning: implicit declaration of function 'uuid_generate_random'
> util.c:87: warning: implicit declaration of function 'uuid_unparse_lower'
> util.c:82: warning: unused variable 'uu'
> make[3]: *** [util.lo] Error 1

lib/gibber/Makefile.am should add UUID_CFLAGS to Makefile.am, but doesn't.

(In reply to comment #1)
> lib/gibber/Makefile.am should add UUID_CFLAGS to Makefile.am, but doesn't.

Er, src/Makefile.am, even... but it does. So, something is wrong in your version of libuuid... the pkg-config test is finding it, but then producing the wrong CFLAGS, or something.

What output do you get for these commands?

pkg-config --exists uuid ; echo $?
pkg-config --cflags uuid
pkg-config --libs uuid

and where are your libuuid.so and uuid.h located?

(In reply to comment #0)
> gibber-resolver.c: In function 'gibber_resolver_res_query_to_list':

We've deleted this file, so, RESOLVED FIXED :-)

> asyncns.c: In function 'handle_request':

This one, too.

> util.c: In function 'gabble_generate_id':
> util.c:82: error: storage size of 'uu' isn't known
> util.c:86: warning: implicit declaration of function 'uuid_generate_random'
> util.c:87: warning: implicit declaration of function 'uuid_unparse_lower'
> util.c:82: warning: unused variable 'uu'

The remaining bug, which, as far as I can see, ought to work already; see Comment #2. Jack, could you answer the questions I asked there please?

It appears OpenBSD have a patch for this too [1], so I've cc'd the OpenBSD maintainer. Jasper, if you can answer my questions from Comment #2 for OpenBSD, that might shed some light on this? You really shouldn't need that patch, unless uuid.pc is rather different on *BSD: on Linux, it adds -I/usr/include/uuid, so including <uuid.h> is correct.

<uuid/uuid.h> seems incorrect, because that assumes that the *parent* directory is on the -I path; if your libuuid was installed in /opt/mypackages or something, then that would fail, because /opt/mypackages/include wouldn't be in the -I path, but -I/opt/mypackages/include/uuid is added by pkg-config.

[1] http://www.openbsd.org/cgi-bin/cvsweb/ports/net/telepathy/telepathy-gabble/patches/patch-src_util_c?rev=1.3

The uuid from our devel/uuid appears too old, so I've patched our port to use the newer uuid from e2fsprogs.

The first one uses include/uuid.h while the latter one uses include/uuid/uuid.h to prevent a conflict between the too.

gurthang:jasper {2001} pkg-config --exists uuid ; echo $?
1
gurthang:jasper {2002}

The relevant cvsweb pages are:
http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/uuid/ (the one that's too old)
http://www.openbsd.org/cgi-bin/cvsweb/ports/sysutils/e2fsprogs/ (the one we use)

(In reply to comment #4)
> The uuid from our devel/uuid appears too old, so I've patched our port to use
> the newer uuid from e2fsprogs.

It seems your "uuid" is from ossp.org. It isn't the same library at all, so it's not surprising if it isn't compatible! In Debian, this one is packaged as ossp-uuid, with the SONAME and the name in pkg-config changed.

Because Debian repackages it to coexist with e2fsprogs' uuid, I hadn't realised that both upstreams provide uuid.pc, with incompatible APIs. I'm opening bugs asking them to provide <ossp-uuid.h> and <e2fs-uuid.h> or something, in addition to the colliding names, with corresponding pkg-config files.

The one from e2fsprogs is indeed the one we intended Gabble to use.

Perhaps you could get the OSSP uuid port in OpenBSD changed to use /usr/include/ossp/uuid.h and put -I/usr/include/ossp in its pkg-config flag? Then it'd be possible to select either version to provide <uuid.h>, by setting -I/usr/include/ossp or -I/usr/include/uuid, without accidentally getting the "chosen" /usr/include/uuid.h turning up when unwanted.

(In reply to comment #5)
> I'm opening bugs
> asking them to provide <ossp-uuid.h> and <e2fs-uuid.h> or something

e2fsprogs: https://sourceforge.net/tracker/?func=detail&aid=3076666&group_id=2406&atid=352406

OSSP: http://cvs.ossp.org/tktview?tn=181

(In reply to comment #5)
> (In reply to comment #4)
> > The uuid from our devel/uuid appears too old, so I've patched our port to use
> > the newer uuid from e2fsprogs.
> 
> It seems your "uuid" is from ossp.org. It isn't the same library at all, so
> it's not surprising if it isn't compatible! In Debian, this one is packaged as
> ossp-uuid, with the SONAME and the name in pkg-config changed.
> 
> Because Debian repackages it to coexist with e2fsprogs' uuid, I hadn't realised
> that both upstreams provide uuid.pc, with incompatible APIs. I'm opening bugs
> asking them to provide <ossp-uuid.h> and <e2fs-uuid.h> or something, in
> addition to the colliding names, with corresponding pkg-config files.
> 
> The one from e2fsprogs is indeed the one we intended Gabble to use.
> 
> Perhaps you could get the OSSP uuid port in OpenBSD changed to use
> /usr/include/ossp/uuid.h and put -I/usr/include/ossp in its pkg-config flag?
> Then it'd be possible to select either version to provide <uuid.h>, by setting
> -I/usr/include/ossp or -I/usr/include/uuid, without accidentally getting the
> "chosen" /usr/include/uuid.h turning up when unwanted.

Good point, Ill take care of this.

Note that this is fixed upstream by removing dependency to libuuid. Should this be considered for inclusion in stable 0.10 branch ?

(In reply to comment #8)
> Note that this is fixed upstream by removing dependency to libuuid. Should this
> be considered for inclusion in stable 0.10 branch ?

Backport the removal into 0.10 you mean?

(In reply to comment #8)
> Note that this is fixed upstream by removing dependency to libuuid. Should this
> be considered for inclusion in stable 0.10 branch ?

Yes, I think that'd be appropriate. Cherry-picking the patch is probably enough.

Fixed in stable 0.10 branch too. Will be available in the next stable release (will be 0.10.3).

(In reply to comment #11)
> Fixed in stable 0.10 branch too. Will be available in the next stable release
> (will be 0.10.3).

Thanks!