Re: Installation Report for powerpc-apple-netbsdelf1.5
От | Patrick Welche |
---|---|
Тема | Re: Installation Report for powerpc-apple-netbsdelf1.5 |
Дата | |
Msg-id | 20000727104646.B23775@quartz.newn.cam.ac.uk обсуждение исходный текст |
Ответ на | Re: Installation Report for powerpc-apple-netbsdelf1.5 ("Henry B. Hotz" <hotz@jpl.nasa.gov>) |
Ответы |
Re: Installation Report for powerpc-apple-netbsdelf1.5
|
Список | 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
В списке pgsql-hackers по дате отправления: