Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luca Pizzamiglio <luca.pizzamiglio@gmail.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: wrong bfd recognized
Date: Mon, 02 Jan 2012 10:04:00 -0000	[thread overview]
Message-ID: <CAB88xy-hiFy2RF7mku2yCS20ywBs3SUumjowfhwqi6OB3jaWAA@mail.gmail.com> (raw)
In-Reply-To: <20111229121739.GU23376@adacore.com>

Hi Joel,

sorry for the confusion, I'm not used to write this kind of ChangeLog
entry. My fault.

2012-01-02 Luca Pizzamiglio <luca.pizzamiglio@gmail.com>

    * gdb/configure.ac (LDFLAGS in ELF support's check): changing path
priority in LDFLAGS
    LDFLAGS is redefined putting an external-defined value at the end.

I hope that works now! This rules doesn't fit well with autoconf files :)
Feel free to modify it, if it's still wrong.

thanks for the support

Luca

On Thu, Dec 29, 2011 at 1:17 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> Luca
>
>> > Could you write a ChangeLog entry for your patch?
>> > I will put it in.
> [...]
>> Ok. A possible entry could be:
>>
>> improved bfd local static library detection in the configure script
>
> Unfortunately, this is not what a ChangeLog entry should look like.
> I suspect you thought that we were asking for some text to be used
> as revision history?  Here is what a ChangeLog entry looks like:
>
> 2011-12-27  Doug Evans  <dje@google.com>
>
>        * dwarf2read.c (struct dwarf2_cu): Delete members first_fn, last_fn,
>        cached_fn.
>        (struct function_range): Delete.
>        (initialize_cu_func_list, add_to_cu_func_list): Delete.  All callers
>        updated.
>        (check_cu_functions): Ditto.
>
> You can have a look at the couple of sections that explain ChangeLogs
> in the GNU Coding Standards (the link brings you directly to the
> relevant section):
>
>    http://www.gnu.org/prep/standards/standards.html#Change-Logs
>
> Please let me know if you have any problems creating one and I will
> write it for you (this time!).
>
> --
> Joel


  reply	other threads:[~2012-01-02 10:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-13 15:29 Luca Pizzamiglio
2011-12-20 14:58 ` Tom Tromey
2011-12-21 12:24   ` Luca Pizzamiglio
2011-12-21 18:50     ` Tom Tromey
2011-12-29 12:18       ` Luca Pizzamiglio
2011-12-29 19:02         ` Joel Brobecker
2012-01-02 10:04           ` Luca Pizzamiglio [this message]
2012-02-06 19:33             ` Tom Tromey
2012-02-07 16:25               ` Luca Pizzamiglio
2012-02-07 20:15 ` Pedro Alves
2012-02-10 13:55   ` Pedro Alves
2012-02-10 13:59     ` Luca Pizzamiglio
2012-02-10 14:02       ` Pedro Alves

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=CAB88xy-hiFy2RF7mku2yCS20ywBs3SUumjowfhwqi6OB3jaWAA@mail.gmail.com \
    --to=luca.pizzamiglio@gmail.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /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