public inbox for
 help / color / mirror / Atom feed
From: "Mark D. Baushke" <>
To: "Mike M. Volokhov" <>
Subject: Re: gnatsd problems with 4.0.1
Date: Mon, 07 Feb 2005 17:15:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Mike M. Volokhov <> writes:

> On Thu, 6 Jan 2005 11:04:35 -0600
> Chad Walstrom <> wrote:
> First, excuse me please for the delayed answer. :-(
> > Mike M. Volokhov wrote:
> > > Could you explain me please what a reason to have libiberty code in
> > > GNATS tree?
> > 
> > For historical and supposedly portability reasons.  Frankly, I'm not
> > that comfortable with it being there.  I haven't had much time lately,
> > but I'd love to audit the GNATS codebase to find out what functions in
> > ./libiberty are actually being used and decide either to adopt them
> > completely by moving them into the ./gnats directory OR drop them
> > completely.  There was a lot of cruft pulled in from my last update.  We
> > can always roll back the CVS to the point before the libiberty update
> > (which I've been contemplating since the day I mistakenly committed it
> > to TRUNK rather than the dev branch like I wanted).
> > 
> > Any opinions in either direction?
> Yes, that's exactly I've asked why. Including libiberty in GNATS
> codebase depends on how much it is used by the project.  Unfortunately,
> libiberty itself seems have not official distribution and in addition it
> may provide some functionality which cannot be acheived by standard C
> library.
> > If someone is willing to do the audit, let me know.  It may not take
> > much time, but most of my spare time right now is going toward a
> > certification class, :-/, and caring for my son, :-).
> I've done some sort of GNATS sources audit to know how much project
> dependends on libiberty code. Well, seems it is not too hard dependent!
> I've used libiberty.h header file to obtain a list of provided functions
> and ran a simple script across gnats/*.[ch] files. It shows a results at
> the end of this mail message.
> So, only six functions are used by GNATS, when libiberty provides about
> 40. Only two functions (asprintf and vasprintf) are nor POSIX nor
> standard C relevant (but included in both GNU and BSD libc). Three
> functions (xstrdup, xmalloc, xrealloc) are totally libiberty-own, but
> can be easy replaced with their standard equivalents.
> Thus, I propose to eliminate dependency on libiberty completely.
> Any comments?

I would suggest consideration of including the GNULIB versions of those
functions as an alternative.

This is much easier than trying to keep libiberty up-to-date.

  cvs -d co gnulib

this does probably make a vote of moving to a use of autoconf and
automake as a part of building the configure and related files in
order to make this easier to use.

The typical approach would be to create a lib and m4 directory for
including the relevant code from a gnulib checkout directory into the
gnats source base. There is a tool that can be used to pull into the
gnats tree any module that GNULIB provides.

See the gnulib/README after you checkout a copy of it.

	-- Mark

Help-gnats mailing list

  reply	other threads:[~2005-02-07 17:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-05 18:23 Tim Buck
2005-01-05 22:24 ` Chad Walstrom
2005-01-06  9:18   ` Mike M. Volokhov
2005-01-06 17:07     ` Chad Walstrom
2005-02-07 15:47       ` Mike M. Volokhov
2005-02-07 17:15         ` Mark D. Baushke [this message]
2005-02-07 19:17           ` Chad Walstrom
2005-02-09 12:50           ` Removing libiberty (was Re: gnatsd problems with 4.0.1) Mike M. Volokhov
2005-02-09 17:15             ` Mark D. Baushke
2005-02-07 17:45         ` Chad Walstrom
2005-02-09 10:56           ` Mike M. Volokhov
     [not found]             ` <>
     [not found]               ` <>
2005-02-24 22:17                 ` Soon to come: RC3 Chad Walstrom
2005-02-24 22:40                   ` RC2 (was Re: Soon to come: RC3) Chad Walstrom
2005-01-06 16:03   ` gnatsd problems with 4.0.1 Tim Buck

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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).