RE: gdb 6.7.1 hppa64-hp-hpux11.11 "needs" _XOPEN_SOURCE_EXTENDED for various errors

[Jay <jay.krell@cornell.edu>]

Joel,
 
  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.
 
 
I'm /hoping/ to fall under the small/trivial caveat. Thanks.
 
 
 
> to have a pa-hpux machine at home (considering the size and price
> of these things)
 
 eBay, older machine, messy home, cheap. :) 
 (See also Irix, IA64, SPARC, AIX... :) )
 
 
> for instance if this macro should be defined if the HP/UX C compiler 

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 source, a bunch of static libraries are on the system compromising the kernel, and the kernel is relinked, for certain sorts of updates.
 
 
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. :)
 
 
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.
 
 
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 standard compliance. You know, imagine old code that used int in place of socklen_t. As long as they don't ask for standard compliance and as long as the actual values fit in an int (highly likely), they remain source compatible even through the change to 64 bits -- assuming there is some additional mechanism to map the two prototypes down to the same code, not a crazy assumption, that sort of thing is done all the time, like e.g. stat vs. stat64.
 
 
"X/Open" is yet another standard or name for a standard among the Posix/Ansi/XOpen/XPG/OpenGroup soup. There are so many, I don't know which is which. :(
 
 
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. :) )
 
 
There are at least two approaches.
 
 
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. If they succeed either way, probably omit it. If they fail either way, probably fail right there. I've seen these patterns applied a bit incorrectly though. For example, they other compiler switches are not maintained as they will be later, like the presence/absence of -Werror -- the successful compile might have warned, and configuration 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.
 
 
The other way would be like #ifdef __hpux #define _XOPEN #endif and done.
At the end of config.in probably.
 
 
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.
 
 
- 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='-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