bug-m4
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

configure failures [was: m4-1.4.15 on Haiku]


From: Eric Blake
Subject: configure failures [was: m4-1.4.15 on Haiku]
Date: Fri, 31 Dec 2010 13:59:52 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]