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

From: Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk>
To: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
Cc: PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Installation Report for powerpc-apple-netbsdelf1.5
Date: 2000-07-27 09:46:46
Message-ID: 20000727104646.B23775@quartz.newn.cam.ac.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 26, 2000 at 02:20:11PM -0700, Henry B. Hotz wrote:
> At 4:25 PM +0100 7/26/00, Patrick Welche wrote:
>
> >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
> > -lpq.2 => not found
...
> >Then I need to relink psql with -Wl,-R/usr/local/pgsql/lib ...
... abridged
> macbsd: {3} ldd /usr/pkg/bin/psql
> /usr/pkg/bin/psql:
> -lpq.2 => /usr/pkg/lib/libpq.so.2
> /usr/local/bin/psql:
> -lpq.2 => not found
>
> 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.

The package probably slaps the -Wl,-R/usr/pkg/lib in. The point of the
above is "use LD_LIBRARY_PATH or ldconfig" isn't a solution for us lot,
the -Wl,-R (or -rpath) is needed (say configure --not-Debian or something ;)

> > > > 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.

Fair enough - same here. The maxproc business for me would be that a new
backend can't be forked for a given test => it doesn't output anything
other than an error message => the test fails. What sort of errors are
you getting?

Cheers,

Patrick

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 2000-07-27 10:16:54 Re: INET/CIDR types
Previous Message Vladimir Terziev 2000-07-27 08:36:28 Large text insertion