On Sat, Mar 04 2006 - 12:35, Jeremy C. Reed wrote: > On Sat, 4 Mar 2006, Joel CARNAT wrote: > > > well... in fact I saw that but couldn't change it ; so I thought I was > > looking at the wrong one. > > > > # sysctl -w proc.curproc.rlimit.stacksize.hard=16777216 > > proc.curproc.rlimit.stacksize.hard: 8388608 -> 16777216 > > Instead of using "curproc" use a specific process ID. > same issue when specifying PID. I also did try to build www/php4 on my i386. And tada... no problem there. So I tried copy/paste rlimit value from i386 to sparc64 and vice-versa. Still no luck on sparc64 and installation OK on i386. > > # sysctl proc.curproc.rlimit.stacksize > > proc.curproc.rlimit.stacksize.soft = 8388608 > > proc.curproc.rlimit.stacksize.hard = 8388608 > > > > # ulimit -s 16384 > > # ulimit -a > > time(cpu-seconds) unlimited > > file(blocks) unlimited > > coredump(blocks) unlimited > > data(kbytes) 1048576 > > stack(kbytes) 8192 > > I don't know. > > I think the error came from the PHP itself. Maybe it is running the > interpreter. > > Maybe try increasing the limit in the php.ini. I am not sure of best way > to do that duing a pkgsrc installation though. > I've deleted any php binary found from previous install. Removed previous php.ini, restored it verifying memory_limit is more than 8M. As nothing related to php was installed on my i386, maybe the issue in the update more than the installation. Gonna try a clean update (with pkg_chk)...
Attachment:
pgpvViIjVqr0m.pgp
Description: PGP signature