From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21219 invoked by alias); 23 Feb 2009 03:13:20 -0000 Received: (qmail 21207 invoked by uid 22791); 23 Feb 2009 03:13:19 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_74,SPF_PASS X-Spam-Check-By: sourceware.org Received: from col0-omc1-s16.col0.hotmail.com (HELO col0-omc1-s16.col0.hotmail.com) (65.55.34.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Feb 2009 03:13:13 +0000 Received: from COL101-W83 ([65.55.34.9]) by col0-omc1-s16.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 19:13:12 -0800 Message-ID: From: Jay To: CC: Subject: RE: gdb 6.7.1 hppa64-hp-hpux11.11 "needs" _XOPEN_SOURCE_EXTENDED for various errors Date: Mon, 23 Feb 2009 03:28:00 -0000 In-Reply-To: <20090223025528.GD26056@adacore.com> References: <20090223025528.GD26056@adacore.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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/msg00433.txt.bz2 Joel, =20 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 mislead= ing, but it is too convenient to pass up. =20 =20 I'm /hoping/ to fall under the small/trivial caveat. Thanks. =20 =20 =20 > to have a pa-hpux machine at home (considering the size and price > of these things) =20 eBay, older machine, messy home, cheap. :)=20 (See also Irix, IA64, SPARC, AIX... :) ) =20 =20 > for instance if this macro should be defined if the HP/UX C compiler=20 The bundled HP-UX compiler is /almost/ useless. It is K&R only, I think doesn't support -g or any optimization. It in the system at least/however, so that a limited form of kernel rebuild= can be done. Some "tunables" or some data, not sure which are built in sou= rce, a bunch of static libraries are on the system compromising the kernel,= and the kernel is relinked, for certain sorts of updates. =20 =20 The unbundled compiler is expensive. What you can do, per the gcc docs, is build gcc 3.3.6 with the bundled one. That gcc doesn't support -g, since it is using bundled as, but can be used = to build current binutils, then rebuild gcc with GNU binutils, and then you= are off and running. :) =20 =20 The docs also suggest building binutils first with bundled cc. That saves you one extra build of gcc. But that doesn't work with current binutils but might circa binutils 2.14 -= - it builds but I didn't use it furthe. I owe this report to the gcc list, = maybe update the docs. =20 =20 The macro is a somewhat random thing throughout /usr/include. It is like, you know, _POSIX_C_SOURCE, _GNU_SOURCE, etc. It is a combination of exposing additional standardized stuff, and changing= older interfaces to be standard-compliant. In this case, to gain the stand= ard compliance. You know, imagine old code that used int in place of sockle= n_t. As long as they don't ask for standard compliance and as long as the a= ctual values fit in an int (highly likely), they remain source compatible e= ven through the change to 64 bits -- assuming there is some additional mech= anism to map the two prototypes down to the same code, not a crazy assumpti= on, that sort of thing is done all the time, like e.g. stat vs. stat64. =20 =20 "X/Open" is yet another standard or name for a standard among the Posix/Ans= i/XOpen/XPG/OpenGroup soup. There are so many, I don't know which is which.= :( =20 =20 I realize my "patch" isn't in the right form but I'm too lazy/ignorant/impa= tient. This is more of a bug report and if someone can form it into a proper confi= gured patch, or send me one to test, great. (That addresses the copyright i= ssue too. :) ) =20 =20 There are at least two approaches. =20 =20 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 s= ucceed the other way, put in the define. If they succeed either way, probab= ly omit it. If they fail either way, probably fail right there. I've seen t= hese patterns applied a bit incorrectly though. For example, they other com= piler switches are not maintained as they will be later, like the presence/= absence of -Werror -- the successful compile might have warned, and configu= ration ignored it but actualy build not. I have seen this for example when = the test was compile+link and the function was not declared, but it linked = ok and then later -Werrored for lack of a prototype. =20 =20 The other way would be like #ifdef __hpux #define _XOPEN #endif and done. At the end of config.in probably. =20 =20 At the very least, by sending this mail, maybe someone searching the web fo= r "HP-UX" and "gdb" will find the fix. I know that's lame, sorry. =20 =20 - Jay ---------------------------------------- > Date: Sun, 22 Feb 2009 18:55:28 -0800 > From: brobecker@ > To: jay.krell@ > CC: gdb-patches@ > Subject: Re: gdb 6.7.1 hppa64-hp-hpux11.11 "needs" _XOPEN_SOURCE_EXTENDED= for various errors > > Jay, > > It looks like you're on your way to send a collection of patches, > which is great :). However, do you have a copyright assignment > on file with the FSF? For a couple of small changes, we can accept > them under the "Small change" / "obvious" rule, but past this, > it is much better for you to have a copyright assignement. > > Your email address has a domain name of a university, so I have to > direct your attention to ownership of the changes you are making > if you are using the university's equipment to make the changes > you are submitting. I think it's relatively uncommon for someone > to have a pa-hpux machine at home (considering the size and price > of these things). Anyway, sometimes, universities claim ownership > of all work done using their equipment, so it becomes harder to > submit them for inclusion in the FSF tree. I see that Cornell University > has a copyright assignment for emacs, so the same might be needed for > GDB. While you're at it, why not ask them if they would be willing to > actually assign all changes for any GNU project? > > If you would like to start the process for getting your assignment > filed with the FSF, please contact me privately, and I will be happy > to get you started. This takes a little while, but do check with > your university. > > Can I also ask you to have a look at the file gdb/CONTRIBUTE that > explains a bit how to submit patches? For isntance, I noticed that > your patches did not include a ChangeLog entry. > > In case of the problem at hand, I am afraid that your patch is not > the best way of handling the problem. As a first measure, I think > it's better to build with CFLAGS=3D'-D_XOPEN_SOURCE_EXTENDED' when > you call "make". I don't know much about this macro, and what its > meaning is, I will double-check when I have a moment, but I wonder > for instance if this macro should be defined if the HP/UX C compiler > was used instead of GCC. Knowing more about this macro will allow us > to implement a change in GDB's configure script that would allow > a developer to build GDB without requiring this manual step. > > -- > Joel