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

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

[Jay]

Building gdb 6.7.1 for hppa64-hp-hpux11.11 (11iv1):
 

32bit already built and minimall works, good.
 

/src/gdb-6.7.1/gdb/ser-tcp.c: In function `net_open':
/src/gdb-6.7.1/gdb/ser-tcp.c:207: warning: passing arg 5 of `getsockopt' from in
compatible pointer type
gmake[2]: *** [ser-tcp.o] Error 1
 

-bash-3.2$ uname -a
HP-UX unknown B.11.11 U 9000/800 1595760578 unlimited-user license
 

CXX=g++64 CC=gcc64 /src/gdb-6.7.1/configure -disable-nls -prefix=/usr/local/64
 
 
-bash-3.2$ gcc64 -v (bootstrapped through bundled K&R cc and gcc 3.3.6..) 
Reading specs from /usr/local/64/lib/gcc/hppa64-hp-hpux11.11/3.4.6/specs
Configured with: /src/gcc-3.4.6/configure -disable-bootstrap -disable-nls -verbo
se -prefix=/usr/local/64 -with-as=/usr/local/64/bin/gas -with-gnu-as
Thread model: single
gcc version 3.4.6
 

-bash-3.2$ g++64 -v  (bootstrapped through bundled K&R cc and gcc 3.3.6..) 
Reading specs from /usr/local/64/lib/gcc/hppa64-hp-hpux11.11/3.4.6/specs
Configured with: /src/gcc-3.4.6/configure -disable-bootstrap -disable-nls -verbo
se -prefix=/usr/local/64 -with-as=/usr/local/64/bin/gas -with-gnu-as
Thread model: single
gcc version 3.4.6
-bash-3.2$
 

I'm still working on getting these to 4.3.3.
 
 
/usr/include/sys/socket.h ROUGHLY reads:
 

#if defined(_XOPEN_SOURCE_EXTENDED)
 
 
/* what you expect */
extern int getsockopt (... socklen_t*);
 
 
#else
 
 
/* not what you expect, but good enough for 32bit */
extern int getsockopt (... int *);
 
 
#endif
 

-bash-3.2$ gdiff -c4 /src/gdb-6.7.1/gdb/ser-tcp.c.orig /src/gdb-6.7.1/gdb/ser-tcp.c
*** /src/gdb-6.7.1/gdb/ser-tcp.c.orig   Sun Feb 22 21:13:35 2009
--- /src/gdb-6.7.1/gdb/ser-tcp.c        Sun Feb 22 21:14:00 2009
***************
*** 17,24 ****
--- 17,25 ----
     You should have received a copy of the GNU General Public License
     along with this program.  If not, see .  */
+ #define _XOPEN_SOURCE_EXTENDED
  #include "defs.h"
  #include "serial.h"
  #include "ser-base.h"
  #include "ser-tcp.h"

 
I realize you'd want something "configured".

 
/src/gdb-6.7.1/gdb/tui/tui-io.c: In function `tui_getc':
/src/gdb-6.7.1/gdb/tui/tui-io.c:681: warning: implicit declaration of function `
napms'
 

Similar problem.

 
/usr/include/curses.h only declares napms under an #ifdef.
I don't know why I didn't see this with 32bit.
 
 
-bash-3.2$ gdiff -u4 /src/gdb-6.7.1/gdb/tui/tui-io.c.orig /src/gdb-6.7.1/gdb/tui/tui-io.c
--- /src/gdb-6.7.1/gdb/tui/tui-io.c.orig        2009-02-22 21:19:11.000000000 -0800
+++ /src/gdb-6.7.1/gdb/tui/tui-io.c     2009-02-22 21:19:25.000000000 -0800
@@ -19,8 +19,9 @@
    You should have received a copy of the GNU General Public License
    along with this program.  If not, see .  */
+#define _XOPEN_SOURCE_EXTENDED
 #include "defs.h"
 #include "target.h"
 #include "event-loop.h"
 #include "event-top.h"
 
 
/src/gdb-6.7.1/gdb/tui/tui-regs.c: In function `tui_display_register':
/src/gdb-6.7.1/gdb/tui/tui-regs.c:553: warning: implicit declaration of function `waddstr'
gmake[2]: *** [tui-regs.o] Error 1
gmake[2]: Leaving directory `/home/jay/obj/gdb/64/gdb'
gmake[1]: *** [all-gdb] Error 2
gmake[1]: Leaving directory `/home/jay/obj/gdb/64'
gmake: *** [all] Error 2
 

_XOPEN_SOURCE_EXTENDED also fixes that.

 
again:
 

/src/gdb-6.7.1/gdb/tui/tui-stack.c: In function `tui_show_locator_content':
/src/gdb-6.7.1/gdb/tui/tui-stack.c:257: warning: implicit declaration of function `waddstr'
gmake[2]: *** [tui-stack.o] Error 1

 
at this point I stopped and put it in config.h, which is perhaps where it belongs.
 
 
Thanks,
 - Jay

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

[Joel Brobecker]

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

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

[Jay]

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

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

[Joel Brobecker]

> 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