Обсуждение: installing uuid generators

Stop me if you've heard this one before :)

Given that pg_config --libdir yields "/usr/lib64"
to where/what would you expect
 "AS '$libdir/uuid-ossp', 'uuid_generate_v5'"

to resolve?

The loader script,
~/tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql,  generates
"tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql:9: ERROR:  could
not access file "$libdir/uuid-ossp": No such file or directory"

On 15/03/10 23:58, Rob Sargent wrote:
> Stop me if you've heard this one before :)
>
> Given that pg_config --libdir yields "/usr/lib64"
> to where/what would you expect
>
>    "AS '$libdir/uuid-ossp', 'uuid_generate_v5'"
>
> to resolve?
>
> The loader script,
> ~/tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql,  generates
> "tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql:9: ERROR:  could
> not access file "$libdir/uuid-ossp": No such file or directory"

Could it be that $libdir doesn't contain uuid-ossp when the .sql script 
is being executed?

It's also worth checking that the pg_config you are executing is the one 
associated with postgresql-8.4.2 - make sure your PATH is set 
appropriately. I'm not sure that it would give this error, but I keep 
making the mistake of setting my PATH with the three versions I have on 
my dev box.

--   Richard Huxton  Archonet Ltd

On 03/16/2010 03:20 AM, Richard Huxton wrote:
> On 15/03/10 23:58, Rob Sargent wrote:
>> Stop me if you've heard this one before :)
>>
>> Given that pg_config --libdir yields "/usr/lib64"
>> to where/what would you expect
>>
>>    "AS '$libdir/uuid-ossp', 'uuid_generate_v5'"
>>
>> to resolve?
>>
>> The loader script,
>> ~/tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql,  generates
>> "tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql:9: ERROR:  could
>> not access file "$libdir/uuid-ossp": No such file or directory"
> 
> Could it be that $libdir doesn't contain uuid-ossp when the .sql script
> is being executed?
> 
> It's also worth checking that the pg_config you are executing is the one
> associated with postgresql-8.4.2 - make sure your PATH is set
> appropriately. I'm not sure that it would give this error, but I keep
> making the mistake of setting my PATH with the three versions I have on
> my dev box.
> 
Thanks for your suggestions.  You were exactly right.  I was pointed at
an 8.3 server in the hinterland, not my own.  Terribly sorry for the
noise. (Of course that fact was staring at me from the sql prompt, which
contains servername :/)

I'm still left worried about the correct procedure for getting uuid-oosp
installed properly on SUSE 11.  Does the server release's contrib
contain uuid-ossp?  I didn't see it on my desktop release.  (I don't
want to have to tell my mates to go through the issues I had building
the lib etc.)

Now I have to clean up after myself for having dropped links to that .so
everywhere!

Thanks again.

On 16/03/10 18:08, Rob Sargent wrote:
> I'm still left worried about the correct procedure for getting uuid-oosp
> installed properly on SUSE 11.  Does the server release's contrib
> contain uuid-ossp?  I didn't see it on my desktop release.  (I don't
> want to have to tell my mates to go through the issues I had building
> the lib etc.)

I'd be surprised if there wasn't a -contrib or -extras rpm with the 
relevant files. The community rpms should have them if the "official" 
Suse ones don't

--   Richard Huxton  Archonet Ltd

Richard Huxton <dev@archonet.com> writes:
> On 16/03/10 18:08, Rob Sargent wrote:
>> I'm still left worried about the correct procedure for getting uuid-oosp
>> installed properly on SUSE 11.  Does the server release's contrib
>> contain uuid-ossp?  I didn't see it on my desktop release.  (I don't
>> want to have to tell my mates to go through the issues I had building
>> the lib etc.)

> I'd be surprised if there wasn't a -contrib or -extras rpm with the 
> relevant files. The community rpms should have them if the "official" 
> Suse ones don't

If there is a contrib rpm but it doesn't seem to contain uuid-ossp,
the likely reason is that the maintainer never got around to adding
--with-ossp-uuid to the build options.  (I know it took me a while
to add that to the Fedora build :-(.)  You could confirm or deny
that theory by looking at the output of pg_config --configure.
If so, file a bug report with SUSE asking for that to be added.
        regards, tom lane

On 03/16/2010 02:26 PM, Tom Lane wrote:
> Richard Huxton <dev@archonet.com> writes:
>> On 16/03/10 18:08, Rob Sargent wrote:
>>> I'm still left worried about the correct procedure for getting uuid-oosp
>>> installed properly on SUSE 11.  Does the server release's contrib
>>> contain uuid-ossp?  I didn't see it on my desktop release.  (I don't
>>> want to have to tell my mates to go through the issues I had building
>>> the lib etc.)
> 
>> I'd be surprised if there wasn't a -contrib or -extras rpm with the 
>> relevant files. The community rpms should have them if the "official" 
>> Suse ones don't
> 
> If there is a contrib rpm but it doesn't seem to contain uuid-ossp,
> the likely reason is that the maintainer never got around to adding
> --with-ossp-uuid to the build options.  (I know it took me a while
> to add that to the Fedora build :-(.)  You could confirm or deny
> that theory by looking at the output of pg_config --configure.
> If so, file a bug report with SUSE asking for that to be added.
> 
>             regards, tom lane

As Tom suspected the SUSE build doesn't name ossp stuff, to wit:
$ pg_config
BINDIR = /usr/bin
DOCDIR = /usr/share/doc/packages/postgresql
HTMLDIR = /usr/share/doc/packages/postgresql
INCLUDEDIR = /usr/include/pgsql
PKGINCLUDEDIR = /usr/include/pgsql
INCLUDEDIR-SERVER = /usr/include/pgsql/server
LIBDIR = /usr/lib64
PKGLIBDIR = /usr/lib64/postgresql
LOCALEDIR = /usr/share/locale
MANDIR = /usr/share/man
SHAREDIR = /usr/share/postgresql
SYSCONFDIR = /usr/etc/postgresql
PGXS = /usr/lib64/postgresql/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--prefix=/usr' '--libdir=/usr/lib64' '--bindir=/usr/bin'
'--includedir=/usr/include/pgsql' '--datadir=/usr/share/postgresql'
'--mandir=/usr/share/man' '--docdir=/usr/share/doc/packages'
'--disable-rpath' '--enable-nls' '--enable-thread-safety'
'--enable-integer-datetimes' '--without-python' '--without-perl'
'--without-tcl' '--with-openssl' '--with-pam' '--with-krb5'
'--with-gssapi' '--with-ldap' '--with-libxml' '--with-libxslt'
'--with-system-tzdata=/usr/share/zoneinfo' 'CFLAGS=-fmessage-length=0
-O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g '
CC = gcc
CPPFLAGS = -D_GNU_SOURCE -I/usr/include/libxml2
CFLAGS = -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g  -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-labels -fno-strict-aliasing -fwrapv
CFLAGS_SL = -fpic
LDFLAGS = -Wl,--as-needed
LDFLAGS_SL =
LIBS = -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lkrb5 -lcom_err
-lgssapi_krb5 -lz -lreadline -lcrypt -ldl -lm
VERSION = PostgreSQL 8.4.2

And I guess --without-perl explains some the machinations necessary to
get bucardo working.

Thanks to all.

Rob Sargent <robjsargent@gmail.com> writes:
> As Tom suspected the SUSE build doesn't name ossp stuff, to wit:

> CONFIGURE = '--prefix=/usr' '--libdir=/usr/lib64' '--bindir=/usr/bin'
> '--includedir=/usr/include/pgsql' '--datadir=/usr/share/postgresql'
> '--mandir=/usr/share/man' '--docdir=/usr/share/doc/packages'
> '--disable-rpath' '--enable-nls' '--enable-thread-safety'
> '--enable-integer-datetimes' '--without-python' '--without-perl'
> '--without-tcl' '--with-openssl' '--with-pam' '--with-krb5'
> '--with-gssapi' '--with-ldap' '--with-libxml' '--with-libxslt'
> '--with-system-tzdata=/usr/share/zoneinfo' 'CFLAGS=-fmessage-length=0
> -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g '

--without-perl? --without-python?  What are these people thinking?
(Personally I don't like --without-tcl either, but I know not so
many people care about that one anymore.)

File an RFE, or find a more clueful distro.
        regards, tom lane