Thread: Problem to configure pg8.3b2 w/ ossp-uuid-support on OS X

Hello.

Compiling PostgreSQL 8.3 beta 2 on OS X 10.4 leads to some configuration
problems, at least for an ordinary user like me -- so please bare with me if
the following is due to user error and not PostgreSQL's fault.

Some necessary notes on my environment:
-- OS X 10.4.10 /w Xcode 2.5.0 (latest dev tools from Apple, incl. gcc
4.0.1)
-- My PostgreSQL installations go to a nonstandard directory, /Library, for
instance /Library/PostgreSQL-8.2  or  /Library/PostgreSQL-8.3
-- I compile PostgreSQL from source, no pre-built binaries, Fink,
DarwinPorts and the like involved
-- Binaries and libraries installed _by the OS itself_ reside in /usr (e.g.
uuid, libxml2, libxslt)
-- I have _updated or alternative versions_ of these three libraries
installed in /usr/local, all are tested and working AFAICS


So to sum up, I have alternative versions of some prerequisites in different
locations. This leads to two problems building PostgreSQL 8.3, one with XSLT
support, one with ossp-uuid. Both problems have a common denominator, I'll
concentrate on ossp-uuid here.

I installed ossp-uuid 1.6.0 and put it in /usr/local.
Configuring the 8.3beta2-build  --with-ossp-uuid  leads to a warning (snip
from the log, complete compilation steps below):
...
checking ossp/uuid.h usability... no
checking ossp/uuid.h presence... no
checking for ossp/uuid.h... no
checking uuid.h usability... no
checking uuid.h presence... yes
configure: WARNING: uuid.h: present but cannot be compiled
configure: WARNING: uuid.h:     check for missing prerequisite headers?
configure: WARNING: uuid.h: see the Autoconf documentation
configure: WARNING: uuid.h:     section "Present But Cannot Be Compiled"
configure: WARNING: uuid.h: proceeding with the preprocessor's result
configure: WARNING: uuid.h: in the future, the compiler will take precedence
configure: WARNING:     ## ---------------------------------------- ##
configure: WARNING:     ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING:     ## ---------------------------------------- ##
checking for uuid.h... yes
checking whether byte ordering is bigendian... yes
...
(end snip)


The reason seems to be that ossp-uuid (in /usr/local) and OS X's built-in
uuid (in /usr) get in each others way: ossp-uuid doesn't use the
'/ossp'-directory layout on OS X (perhaps unless you decide to configure a
quite nonstandard ossp-uuid installation), so there is no 'ossp/uuid', hence
ossp-uuid is present, but it is ignored. Using
--with-libraries=/usr/lib/:/usr/local/lib/ (and --with-includes=...
respectively)  _or_  --with-libraries=/usr/local/lib/:/usr/lib/:  makes no
difference. There may be some tricks to tell PostgreSQL's configure script
to recognize the correct uuid, but that's beyond my skills.


The preferred solution, at least from my limited perspective, would be to
add either/or
-- an environment variable, e.g. UUID_CONFIG (we already have XML2_CONFIG,
for example, and that works pretty well in my case)
-- an option like  --with-uuidconfig=DIR  or  --with-uuid-config=DIR,
comparable to  --with-tclconfig=DIR
  and let it point to the particular uuid's config-program one wants.
I know that problems like this have been discussed during the last months,
but I suspect that either no solution has materialized so far, or I
represent a 'border case'.


Any comments are appreciated
and thanks for your interest.

Regards

Joerg Beyer


P.S.:
Steps used to compile PostgreSQL 8.3 beta 2:

export XML2_CONFIG=/usr/local/bin/xml2-config
export XSLT_CONFIG=/usr/local/bin/xslt-config  ## currently ignored by
configure

./configure --prefix=/Library/PostgreSQL-8.3
--exec-prefix=/Library/PostgreSQL-8.3 --with-pgport=5483
--with-libraries=/usr/local/lib/:/usr/lib/
--with-includes=/usr/local/include/:/usr/include/
--with-system-tzdata=/usr/share/zoneinfo --with-openssl --with-ldap
--with-krb5 --with-pam --with-ldap --with-bonjour --with-readline
--with-libedit-preferred --with-zlib --with-ossp-uuid --with-perl
--with-python --with-tcl --with-tclconfig=/usr/lib --with-libxml
--with-libxslt --disable-nls --disable-integer-datetimes --enable-shared
--enable-rpath --enable-thread-safety --enable-debug --enable-depend
--disable-cassert --disable-dtrace

make
make check
make install ## as superuser


============================================================

Jörg Beyer
PHILIPPS-University Marburg
Dept. of Psychology
Germany

Jörg Beyer <Beyerj@students.uni-marburg.de> writes:
> -- Binaries and libraries installed _by the OS itself_ reside in /usr (e.g.
> uuid, libxml2, libxslt)

What I see on my OSX machines is /usr/include/uuid/uuid.h and no sign of
anything uuid-related in /usr/lib.  (Apparently the functions declared
by uuid/uuid.h reside directly in libc.)  This seems to be a
DCE-compatible library not the OSSP one.  AFAICT our configure script
completely ignores the presence of uuid/uuid.h.

So I'm wondering what exactly you've got in /usr and where it came from.
        regards, tom lane

Am 11.11.2007 17:36 Uhr schrieb Tom Lane (<tgl@sss.pgh.pa.us>):

> Jörg Beyer <Beyerj@students.uni-marburg.de> writes:
>> -- Binaries and libraries installed _by the OS itself_ reside in /usr (e.g.
>> uuid, libxml2, libxslt)
>
> What I see on my OSX machines is /usr/include/uuid/uuid.h and no sign of
> anything uuid-related in /usr/lib.  (Apparently the functions declared
> by uuid/uuid.h reside directly in libc.)  This seems to be a
> DCE-compatible library not the OSSP one.  AFAICT our configure script
> completely ignores the presence of uuid/uuid.h.
>
> So I'm wondering what exactly you've got in /usr and where it came from.
>
> regards, tom lane

Ah, O.K., sorry, I tried not to be too verbose.
'/usr' should read as 'the respective subdirectories in /usr'.

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.

Regards

Jörg Beyer

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