X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Eric Blake Subject: Re: Compiling from cvs and duplicate definition error on strsignal Date: Wed, 18 Jun 2008 22:02:38 +0000 (UTC) Lines: 24 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Brian Keener thesoftwaresource.com> writes: > > I was compiling a debug version of Cygwin after updating from current > cvs (starting from scratch) and got a conflicting types error on > definition of strsignal building libiberty/strsignal.c : > at line 409 of strsignal.c in > /usr/develop/src/src/src/libiberty/strsignal.c > vs > line 79 of string.h in > /usr/develop/src/src/src/newlib/libc/include/string.h. That merely means that both libiberty's strsignal.c and cygwin's strsig.cc conflict with the upcoming POSIX 200x definition of strsignal to return char* rather than const char *, and that they haven't caught up with my newlib patch from this morning where I fixed the same bug in newlib. For that matter, why does building cygwin trigger a build of libiberty, since we obviously don't use libiberty's strsignal.c? The libiberty bug should probably be reported to the gcc and/or gdb list; and I've been meaning to post a patch for cygwin's side of the bug. -- Eric Blake -- 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/