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