Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group