X-Spam-Check-By: sourceware.org
Message-ID: <46609526.304614CC@dessent.net>
Date: Fri, 01 Jun 2007 14:52:38 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Build problems - unistd.h
References: <ee9b16d00705281855m57914fcag37e88f9a52b47315 AT mail DOT gmail DOT com> 	 <ee9b16d00705291413j579cc046vcd3d8d8517c3f6ef AT mail DOT gmail DOT com> 	 <ee9b16d00705291712s4b79ba95u66054f4dc66709a5 AT mail DOT gmail DOT com> 	 <ee9b16d00705302103l50d883aej5e1e30328109b099 AT mail DOT gmail DOT com> 	 <Pine DOT GSO DOT 4 DOT 63 DOT 0705311030070 DOT 13828 AT access1 DOT cims DOT nyu DOT edu> <ee9b16d00706011434h295e1afer8fdd345aac480ae AT mail DOT gmail DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Scott Peterson wrote:

> On that advice, I now get a new error:
> 
> /home/Scott/downloads/dbus-glib-0.73/dbus/dbus-binding-tool-glib.c:800: undefine
> d reference to `_g_file_open_tmp_utf8'
> 
> This is nearly identical to the error I got when commenting out line
> 108 of unistd.h:
> 
> /home/Scott/downloads/dbus-glib-0.73/dbus/dbus-binding-tool-glib.c:799: undefine
> d reference to `_g_file_open_tmp_utf8'
> 
> Note that the errors differ only in their line numbers. Whatever does it mean?

You really should not edit unistd.h or any other system header, ever. 
That's a very bad practice to get into.  If "#undef pipe" in
dbus-binding-tool-glib.c works, then go with that, but even that's a
horrible hack.  The best way would be to find out why this macro that
seems to be relevant only to MinGW/native win32 builds is getting pulled
in for a Cygwin build and report it upstream, otherwise it'll never get
fixed.

The undefined reference looks like a link error, a completely unrelated
and separate failure.  You aren't doing anyone any good by deleting all
of the surrounding context of these errors.  If we had the link command
that produced the error we might be able to spot a problem, like
incorrect ordering of -l arguments or something.  But without that, all
that can be said is "find where that symbol is defined and then find why
the linker can't find it."

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/