the openafs-1.3.2/src/pinstall/install.c program fails. i had to replace fork .... execve("/bin/cp", copy, (char **)0);waitpid(pid, &status, 0) != pid) with a system("/bin/cp .....); and now it works. i do NOT understand the problem. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: the error is manifested w/ this error msg: ranlib libprocmgmt.a /var/tmp/portage/openafs-1.3.2-r1/work/openafs-1.3.2/src/pinstall/pinstall libprocmgmt.a /var/tmp/portage/openafs-1.3.2-r1/work/openafs-1.3.2/lib/libprocmgmt.a Bad exit code from /bin/cp: 139 Could not open output temp file ``/var/tmp/portage/openafs-1.3.2-r1/work/openafs-1.3.2/lib/libprocmgmt.a.linux4'': No such file or directory make[3]: *** [/var/tmp/portage/openafs-1.3.2-r1/work/openafs-1.3.2/lib/libprocmgmt.a] Error 1 make[3]: Leaving directory `/var/tmp/portage/openafs-1.3.2-r1/work/openafs-1.3.2/src/procmgmt' BUT there's another error before that (while building the install program): /var/tmp/portage/openafs-1.3.2-r1/temp/ccuggCcD.o(.text+0xe0): In function `ErrorString': /var/tmp/portage/openafs-1.3.2-r1/work/openafs-1.3.2/src/pinstall/install.c:131: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead /var/tmp/portage/openafs-1.3.2-r1/temp/ccuggCcD.o(.text+0xaf):/var/tmp/portage/openafs-1.3.2-r1/work/openafs-1.3.2/src/pinstall/install.c:128: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead make[3]: Leaving directory `/var/tmp/portage/openafs-1.3.2-r1/work/openafs-1.3.2/src/pinstall'
Created attachment 10584 [details, diff] patch to src/pinstall/install.c
I think the problem is that execve() expects a pointer to a new environment in its second argument, which currently is (char **)0. Using system circumvents this, but (nitpick mode on) intruducing slightly more overhead, because it AFAIK will start a new shell. (nitpick mode of). So I recommend to pass a pointer to a NULL pointer inside the second argument, like execve( "/bin/cp", copy, copy+3 ); . Note that copy+3 will point to a NULL pointer. Unfortunately, I cannot currently submit a patch, the method described works out for me and I'd prefer it to system().
*** Bug 22732 has been marked as a duplicate of this bug. ***
1.3.2 was masked