public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: John Gilmore <gnu@toad.com>
Cc: Hui Zhu <teawater@gmail.com>, gdb@sourceware.org
Subject: Re: Request change name of function lookup_enum in libbabeltrace to make GDB use this lib
Date: Thu, 06 Dec 2012 15:38:00 -0000	[thread overview]
Message-ID: <50C0BBF7.7040100@redhat.com> (raw)
In-Reply-To: <201212061051.qB6Ap9CU012302@new.toad.com>

On 12/06/2012 10:51 AM, John Gilmore wrote:
> I suggest that it's best if both GDB and Libbabeltrace change the name
> of lookup_enum.  That way you'll be able to compile any version of GDB
> with any version of libbabeltrace (fixed or unfixed) and all four
> combinations will work except "unfixed GDB" and "unfixed
> libbabeltrace").
> 
> If you just change it in the library, gdb stops building on machines that
> have the old library.
> 
> If you just change it in GDB, older gdb's won't be compatible with
> newer libraries.  Hmm, but older gdb's don't link with that library
> anyway.  So you might as well just fix it in GDB; that works for all
> cases.

AFAICS, this is a pretty new library.  It isn't even packaged in Fedora
for example.  And this is new functionality.  There's no need to rush this out.

Libraries should be good citizens and put their external visible symbols in
a namespace, which in C amounts to prefixing their symbols with ctf_ or
whatever.  We should not consider adjusting GDB until we're shure upstream
babeltrace has fully addressed the issue (which it seems it will).  Then the
question at that point becomes one of considering whether we want to support
building with the old broken versions or just forget them.

-- 
Pedro Alves

      parent reply	other threads:[~2012-12-06 15:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-05 11:38 Hui Zhu
2012-12-05 12:08 ` [lttng-dev] " Mathieu Desnoyers
2012-12-05 12:22   ` Hui Zhu
2012-12-06 15:57   ` Pedro Alves
2012-12-06 16:21     ` Pedro Alves
2012-12-06 16:25       ` Mathieu Desnoyers
2012-12-10  8:31     ` Hui Zhu
2012-12-10 14:05       ` Mathieu Desnoyers
2012-12-11 15:19         ` Hui Zhu
2012-12-20 13:47           ` Hui Zhu
2012-12-20 14:16             ` Mathieu Desnoyers
2012-12-21  2:58               ` Hui Zhu
2013-01-07 21:19                 ` Mathieu Desnoyers
2013-01-09 19:48                   ` [BABELTRACE PATCH] Namespace the lookup_enum function Julien Desfossez
2013-01-13 17:58                     ` Mathieu Desnoyers
2013-01-24 17:43                       ` [lttng-dev] " Julien Desfossez
2013-01-25 11:17                         ` Hui Zhu
2012-12-06 10:51 ` Request change name of function lookup_enum in libbabeltrace to make GDB use this lib John Gilmore
2012-12-06 12:13   ` Hui Zhu
2012-12-06 15:38   ` Pedro Alves [this message]

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=50C0BBF7.7040100@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=gnu@toad.com \
    --cc=teawater@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).