Re: Installation Report for powerpc-apple-netbsdelf1.5

At 4:25 PM +0100 7/26/00, Patrick Welche wrote:
>I just had a go on NetBSD-1.5C/i386 with a fresh cvs - first time since the
>new autoconf stuff..

They cut 1.5 alpha less than a month ago and they are already up to
1.5C on the development branch? Geesh!

>On Wed, Jul 26, 2000 at 04:02:33AM +0000, Thomas Lockhart wrote:
> > > First problem: ODBC doesn't compile. |-(
>
>I didn't try to compile odbc..

I'll redo this one and email Tom L., er, TGL, er, Thomas the compile log.

> > > Second problem: with elf binaries the location of shared libraries
> > > is supposed to be compiled in so each program can reference its own
> > > set of shared objects without conflict. This doesn't seem to jibe
> > > with how the build/install makefiles do things. I get missing shared
> > > libraries when I try to access the DB as a normal user, and the
> > > mechanism I would have used to fix this on an xcoff system is
> > > deleted, or at least deprecated, on an elf system.
> >
> > There was some discussion recently about whether -rpath is A Good Thing,
> > with Debian voting that it is One Step From Hell. I've always just
> > modified my ld.config and/or my LD_LIBRARY_PATH environment to get to
> > the libraries.
> >
> > Either of these should solve your regression test problem.
>
>As it happens my LD_LIBRARY_PATH is always empty and there is no ldconfig on
>my system, the standard ld.so.conf file on i386 (elf) being
>libm.so.0 machdep.fpu_present 1:libm387.so.0,libm.so.0

On port-macppc there is no ld.so.conf file. Maybe I should post this
question on the NetBSD lists, though it seems more related to ELF
than to *BSD.

>So, any chance of putting -rpath in? Without it you end up with:
>
>% ldd psql
>psql:
> -lpq.2 => not found
> -lz.0 => /usr/lib/libz.so.0
> -lcrypt.0 => /usr/lib/libcrypt.so.0
> -lm.0 => /usr/lib/libm387.so.0
> -lm.0 => /usr/lib/libm.so.0
> -lutil.5 => /usr/lib/libutil.so.5
> -ltermcap.0 => /usr/lib/libtermcap.so.0
> -lcurses.3 => /usr/lib/libcurses.so.3
> -lc.12 => /usr/lib/libc.so.12
>
>Then I need to relink psql with -Wl,-R/usr/local/pgsql/lib ...

FWIW:

macbsd: {3} ldd /usr/pkg/bin/psql
/usr/pkg/bin/psql:
-lcrypt.0 => /usr/lib/libcrypt.so.0
-lc.12 => /usr/lib/libc.so.12
-lpq.2 => /usr/pkg/lib/libpq.so.2
-lm.0 => /usr/lib/libm.so.0
-lutil.5 => /usr/lib/libutil.so.5
-lreadline.4 => /usr/pkg/lib/libreadline.so.4
-ltermcap.0 => /usr/lib/libtermcap.so.0
macbsd: {4} ldd /usr/local/bin/psql
/usr/local/bin/psql:
-lpq.2 => not found
-lcrypt.0 => /usr/lib/libcrypt.so.0
-lm.0 => /usr/lib/libm.so.0
-lutil.5 => /usr/lib/libutil.so.5
-ltermcap.0 => /usr/lib/libtermcap.so.0
-lcurses.3 => /usr/lib/libcurses.so.3
-lc.12 => /usr/lib/libc.so.12

We could go through the package patches to see what they changed to
"fix" the problem if necessary. When built directly into /usr/local
gmake runcheck works and gmake runtest fails (as does initdb, etc).
When built using the package system most normal operations seem OK,
but gmake runtest and runcheck both fail.

=============== installing languages... =================
installing PL/pgSQL .. createlang: missing required argument PGLIB directory
(This is the directory where the interpreter for the procedural
language is stored. Traditionally, these are installed in whatever
'lib' directory was specified at configure time.)
failed

> > > Third problem: well actually the regression tests seem to
>work, mostly. ;-)
>
>Where they the parallel regression tests? Does "unlimit maxproc" help? (I
>usually forget to do this and maxproc=80 isn't enough for me)

Tried it. No change. I did have to stop the running postmaster to
do a gmake runcheck or it fails because it can't get enough shared
memory. I'm running an unoptimized generic kernel.

>All the tests bar geometry work for me, but the latter has:
>! ERROR: parser: parse error at or near "("
>in amongst the rounding errors..

I don't get that error. I admit I didn't look exhaustively for
non-rounding errors in the diff.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h(dot)b(dot)hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu