From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27504 invoked by alias); 23 Feb 2009 03:28:41 -0000 Received: (qmail 27496 invoked by uid 22791); 23 Feb 2009 03:28:40 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Feb 2009 03:28:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 986822BAB60; Sun, 22 Feb 2009 22:28:36 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TrpfdFUK6nWP; Sun, 22 Feb 2009 22:28:36 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 3B1A02BAB5E; Sun, 22 Feb 2009 22:28:36 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id D8D8CE7ACD; Sun, 22 Feb 2009 19:28:31 -0800 (PST) Date: Mon, 23 Feb 2009 07:19:00 -0000 From: Joel Brobecker To: Jay Cc: gdb-patches@sourceware.org Subject: Re: gdb 6.7.1 hppa64-hp-hpux11.11 "needs" _XOPEN_SOURCE_EXTENDED for various errors Message-ID: <20090223032831.GG26056@adacore.com> References: <20090223025528.GD26056@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00435.txt.bz2 > Sorry, I don't have copyright assignment, I won't likely, I've long > since graduated but have email forwarding for life. I'm sorry if > that is misleading, but it is too convenient to pass up. [...] > eBay, older machine, messy home, cheap. :) > (See also Irix, IA64, SPARC, AIX... :) ) That's very good news, because it actually simplifies the equation enormously. If you're doing these changes on your own time with your own equipment, the only person involve is just you :). > I'm /hoping/ to fall under the small/trivial caveat. Thanks. The one change I just checked in did indeed fall under the "Not Legally Significant" rule. More patches can be accepted under the same rule provided that they remain small and relatively trivial. However, when it appears that the contribute is going to send more than a couple of patches, it's better if we have the copyright assignment on file. The FSF provides the following guidelines: A change of just a few lines (less than 15 or so) is not legally significant for copyright. A regular series of repeated changes, such as renaming a symbol, is not legally significant even if the symbol has to be renamed in many places. Keep in mind, however, that a series of minor changes by the same person can add up to a significant contribution. What counts is the total contribution of the person; it is irrelevant which parts of it were contributed when. As you can see, we're going to reach the limit pretty soon. [about building GCC on HP/UX] You are very courageous :-). You may want to install one of the GCC binary packages that HP provides... > I realize my "patch" isn't in the right form but I'm too > lazy/ignorant/impatient. This is more of a bug report and if someone > can form it into a proper configured patch, or send me one to test, > great. (That addresses the copyright issue too. :) ) OK, there is nothing wrong with that. > The "completely configured" way, where a few snippets of code are > attemped to be compiled, with and without the define, and if they fail > one way and succeed the other way, put in the define. This is unusual, and I would prefer a different approach if we can. This all depends on what the macro is for. Could we just build *all* files with -D_XOPEN[...] when on HP/UX? If this is meant to be used only with a GNU compiler, then we can extend the check to GCC-only. These are just ideas if you'd like to dig deeper. > The other way would be like #ifdef __hpux #define _XOPEN #endif and done. > At the end of config.in probably. We try to stay away from this kind of practice. We rely on the configure script for that. > At the very least, by sending this mail, maybe someone searching the > web for "HP-UX" and "gdb" will find the fix. I know that's lame, > sorry. No, that's totally fine. This might be helpful to others. Note that if you spend the extra effort of contributing an acceptable patch, then once contributed, you won't have to redo the work when you move to the next version of GDB, which may be packed of features you might be interested in ;-). -- Joel