From: Joel Brobecker <brobecker@adacore.com>
To: Jay <jay.krell@cornell.edu>
Cc: gdb-patches@sourceware.org
Subject: Re: gdb 6.7.1 hppa64-hp-hpux11.11 "needs" _XOPEN_SOURCE_EXTENDED for various errors
Date: Mon, 23 Feb 2009 03:13:00 -0000 [thread overview]
Message-ID: <20090223025528.GD26056@adacore.com> (raw)
In-Reply-To: <COL101-W5195D0733746EA5AC6473EE6AE0@phx.gbl>
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
next prev parent reply other threads:[~2009-02-23 2:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 2:55 Jay
2009-02-23 3:13 ` Joel Brobecker [this message]
2009-02-23 3:28 ` Jay
2009-02-23 7:19 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090223025528.GD26056@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=jay.krell@cornell.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox