On 09/24/2010 10:12 PM, scott mc wrote: > Here's my work-in-progress patch for 1.4.15: > http://ports.haiku-files.org/browser/haikuports/trunk/sys-devel/m4/patches/m4-1.4.15.patch
The patch to src/m4.c is unnecessary. It may not be optimal to install a signal handler multiple times, but it is harmless. The course of actions is: sigaction (SIGSEGV) sigaction (SIGBUS) c_stack_action () with the net result that the single signal SIGSEGV/SIGBUS is ultimately handled by just the c_stack_action handler. I'm still trying to understand why you think lib/pipe2.c needs a patch. pipe2.c includes "binary-io.h", which correctly undefines O_BINARY and O_TEXT as worthless on Haiku, then redefines them as 0. Oh, maybe I see the problem - it only redefines O_BINARY as 0, but looks like it leaves O_TEXT undefined. That should be easy to fix in gnulib. > > I built libsigsegv, and configured it in, but i'm getting the missing > Makefile.in near the end of configure now with or without that > installed. Something weird is going on indeed: checking dependency style of :... mkdir: cannot create directory `conftest.dir': File or Directory already exists cp: accessing `conftest.dir': Bad data ./configure: line 28036: cd: conftest.dir: Not a directory ./configure: line 28047: ./depcomp: No such file or directory none I think what's happening is that a test is botched, but the cd still took place and configure is no longer in the directory where it started. If we can get that fixed (or at the very least, isolate the cd into a subshell so as not to affect the rest of the configure script), then that should solve the Makefile.in not found issue. > > It's also doing some weird thing where I'm not able to easily delete > the directory that I'm working in after it bails out of configuring. > Not sure why that is, as I haven't run into that with any other port > I've worked on. Do you have any means of telling whether some process still has a file handle open? For example, lsof on Linux or ProcessExplorer on Windows can help pinpoint a culprit that is keeping a handle open and thus preventing deletion of the directory. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
