Jörg Beyer <Beyerj@students.uni-marburg.de> writes:
> To be precise, for uuid I have:
> /usr/bin/uuidgen [the CL tool, which should be of no interest here]
> /usr/include/uuid/uuid.h
> and that's the same as you have. Nothing else uuid-related in /usr.
> And yes, AFAICT, uuid-functionalities (a) are part of libc, (b) appear to be
> DCE compatible.
> I have installed _ossp-uuid_ with --prefix=usr/local, so my question is not,
> why pg's configure script ignores OS X's uuid stuff. I'm looking for a way
> to let configure recognize the ossp-uuid library.
OK, I tried the same experiment of installing OSSP uuid 1.6.0 from
source, with no options except --prefix=/usr/local (which I think is
the default anyway). What I find is that it installs/usr/local/include/uuid.h/usr/local/lib/libuuid.dylib (.so to
non-Mac'ers)
So our configure/build process is indeed broken, in that it assumes uuid
is always installed as libossp-uuid.so. I've committed a fix for that.
Note that the original thought about needing --with-includes and/or
--with-libraries is a red herring: at least on OS X with gcc, these
directories are searched anyway. After fixing the library-name
bug, I was able to build fine with just configure --with-ossp-uuid.
The other part of the problem is that you're seeing a configure warning
that uuid.h doesn't compile. This is only cosmetic, because it works
fine when you actually go to build the contrib module. The reason for
the warning is that uuid.h tries to forestall a conflict with built-in
definitions of uuid_t by doing this:
/* workaround conflicts with system headers */
#define uuid_t __vendor_uuid_t
#define uuid_create __vendor_uuid_create
#define uuid_compare __vendor_uuid_compare
#include <sys/types.h>
#include <unistd.h>
#undef uuid_t
#undef uuid_create
#undef uuid_compare
But that only works if <sys/types.h> and/or <unistd.h> haven't already
been included in the current compilation ... and in configure's test
program, <unistd.h> *has* been included. Darwin puts a non-compatible
definition of typedef uuid_t in <unistd.h>, so it goes boom.
Now we can live with this as long as <unistd.h> isn't included
automatically by c.h, which seems to be true except on some old Sun
platforms that probably don't define uuid_t anyway. But it's clearly
trouble waiting to happen, and even more so for other users of libuuid.
IMHO this is a bug in libuuid: they need to find some
include-order-independent way of avoiding their conflict with system
headers. I don't care enough about it to file a bug report, but maybe
someone else does.
regards, tom lane
