public inbox for gnats-devel@sourceware.org
 help / color / mirror / Atom feed
* gnatsd problems with 4.0.1
@ 2005-01-05 18:23 Tim Buck
  2005-01-05 22:24 ` Chad Walstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Tim Buck @ 2005-01-05 18:23 UTC (permalink / raw)
  To: help-gnats

I'm trying to build gnats 4.0.1 on a FreeBSD 5.3/amd64 platform.
It compiles OK, but segfaults when invoked. So I built it with
CFLAGS="-g -Wall" to get debugging symbols in the binary, but this
binary doesn't segfault!

However, the debugging binary doesn't work correctly. Some commands
(such as DBLS) work, but most EXPR commands return "415 invalid
expression" (the same expressions work in gnats 4.0).

Since 4.0 seems to work correctly, I'm sticking with it for now.
But I'd like to stay current, so if you have any ideas about what's
going on please share them! I'll be happy to provide further info
as needed.

Tim Buck * Information Technology Manager * Recognition Research, Inc.
PHONE +1 540 961-6500 * FAX +1 540 961-3568 * EMAIL tbuck@rrinc.com
No one ever went broke underestimating the intelligence of the
American People -- P. T. Barnum




_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gnatsd problems with 4.0.1
  2005-01-05 18:23 gnatsd problems with 4.0.1 Tim Buck
@ 2005-01-05 22:24 ` Chad Walstrom
  2005-01-06  9:18   ` Mike M. Volokhov
  2005-01-06 16:03   ` gnatsd problems with 4.0.1 Tim Buck
  0 siblings, 2 replies; 14+ messages in thread
From: Chad Walstrom @ 2005-01-05 22:24 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 1737 bytes --]

Tim Buck wrote:
> I'm trying to build gnats 4.0.1 on a FreeBSD 5.3/amd64 platform.  It
> compiles OK, but segfaults when invoked. So I built it with CFLAGS="-g
> -Wall" to get debugging symbols in the binary, but this binary doesn't
> segfault!

Hmm... I know there have been some problems recently with the gcc
compilers, libc, and 4.0.x.  I believe it has something to do with the
memcpy() handling in ./libiberty, especially when compiled with
optimizations turned on.  The suggestion has been to turn off
optimizations when you compile.

This was the reason why I tried to update the ./libiberty and ./include
directories in the CVS version of GNATS.  As you experienced, there are
build problems on the FreeBSD platform involving this upgrade.

> However, the debugging binary doesn't work correctly. Some commands
> (such as DBLS) work, but most EXPR commands return "415 invalid
> expression" (the same expressions work in gnats 4.0).

This is strange.  There were no changes to the regex code between 4.0
and 4.0.1.  Have you tested simple expressions as well as more complex
ones?  If you could share what you've tried, perhaps we can test on our
own as well.

> Since 4.0 seems to work correctly, I'm sticking with it for now.  But
> I'd like to stay current, so if you have any ideas about what's going
> on please share them! I'll be happy to provide further info as needed.

The "exploit" possibility in gnats <= 4.0 is fairly remote, if not well
neigh impossible.  Sticking with gnats 4.0 is fine, though I would like
to make things work for you in 4.0.1.

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gnatsd problems with 4.0.1
  2005-01-05 22:24 ` Chad Walstrom
@ 2005-01-06  9:18   ` Mike M. Volokhov
  2005-01-06 17:07     ` Chad Walstrom
  2005-01-06 16:03   ` gnatsd problems with 4.0.1 Tim Buck
  1 sibling, 1 reply; 14+ messages in thread
From: Mike M. Volokhov @ 2005-01-06  9:18 UTC (permalink / raw)
  To: help-gnats

On Wed, 5 Jan 2005 16:24:35 -0600
Chad Walstrom <chewie@wookimus.net> wrote:

> Tim Buck wrote:
> > I'm trying to build gnats 4.0.1 on a FreeBSD 5.3/amd64 platform.  It
> > compiles OK, but segfaults when invoked. So I built it with CFLAGS="-g
> > -Wall" to get debugging symbols in the binary, but this binary doesn't
> > segfault!
> 
> Hmm... I know there have been some problems recently with the gcc
> compilers, libc, and 4.0.x.  I believe it has something to do with the
> memcpy() handling in ./libiberty, especially when compiled with
> optimizations turned on.  The suggestion has been to turn off
> optimizations when you compile.
> 
> This was the reason why I tried to update the ./libiberty and ./include
> directories in the CVS version of GNATS.  As you experienced, there are
> build problems on the FreeBSD platform involving this upgrade.

Greetings!

Could you explain me please what a reason to have libiberty code in GNATS tree?

--
TIA,
Mishka.


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gnatsd problems with 4.0.1
  2005-01-05 22:24 ` Chad Walstrom
  2005-01-06  9:18   ` Mike M. Volokhov
@ 2005-01-06 16:03   ` Tim Buck
  1 sibling, 0 replies; 14+ messages in thread
From: Tim Buck @ 2005-01-06 16:03 UTC (permalink / raw)
  To: Chad Walstrom; +Cc: help-gnats


On Jan 5, 2005, at 5:24 PM, Chad Walstrom wrote:

> Tim Buck wrote:
>> However, the debugging binary doesn't work correctly. Some commands
>> (such as DBLS) work, but most EXPR commands return "415 invalid
>> expression" (the same expressions work in gnats 4.0).
>
> This is strange.  There were no changes to the regex code between 4.0
> and 4.0.1.  Have you tested simple expressions as well as more complex
> ones?  If you could share what you've tried, perhaps we can test on our
> own as well.

Here's a very simple example. This query string was generated by
GNATSweb. Both versions of GNATS were built on the same machine &
platform (FreeBSD 5.3/amd64):

using GNATS 4.0:
200 maytag.rrinc.com GNATS server 4.0 ready.
CHDB default
210-Now accessing GNATS database 'default'
210 User access level set to 'edit'
EXPR (State[type]!="closed") & (Responsible~"^tim$")
210 Ok.

using GNATS 4.0.1:
200 maytag.rrinc.com GNATS server 4.0.1 ready.
CHDB default
210-Now accessing GNATS database 'default'
210 User access level set to 'edit'
EXPR (State[type]!="closed") & (Responsible~"^tim$")
415 Invalid expression.

However, if I use a simpler version of that expression without the
extraneous parentheses (rather than the one generated from GNATSweb),
it works:

200 maytag.rrinc.com GNATS server 4.0.1 ready.
CHDB default
210-Now accessing GNATS database 'default'
210 User access level set to 'edit'
EXPR State[type]!="closed" & Responsible~"tim"
210 Ok.

I hope this info helps.

Tim Buck * Information Technology Manager * Recognition Research, Inc.
PHONE +1 540 961-6500 * FAX +1 540 961-3568 * EMAIL tbuck@rrinc.com
The only thing to do with good advice is to pass it on. -- Oscar Wilde




_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gnatsd problems with 4.0.1
  2005-01-06  9:18   ` Mike M. Volokhov
@ 2005-01-06 17:07     ` Chad Walstrom
  2005-02-07 15:47       ` Mike M. Volokhov
  0 siblings, 1 reply; 14+ messages in thread
From: Chad Walstrom @ 2005-01-06 17:07 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 1098 bytes --]

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?

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, :-).

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gnatsd problems with 4.0.1
  2005-01-06 17:07     ` Chad Walstrom
@ 2005-02-07 15:47       ` Mike M. Volokhov
  2005-02-07 17:15         ` Mark D. Baushke
  2005-02-07 17:45         ` Chad Walstrom
  0 siblings, 2 replies; 14+ messages in thread
From: Mike M. Volokhov @ 2005-02-07 15:47 UTC (permalink / raw)
  To: help-gnats

On Thu, 6 Jan 2005 11:04:35 -0600
Chad Walstrom <chewie@wookimus.net> 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?

--
Best wishes,
Mishka.

========8<=======8<========8<=======8<========8<=======8<========

The distribution of used libiberty functions accross GNATS sources:
	--- asprintf ---
	8	gnats/file-pr.c
	7	gnats/queue-pr.c
	5	gnats/query-pr.c
	4	gnats/field.c
	4	gnats/gnats-pwconv.c
	4	gnats/pr.c
	3	gnats/misc.c
	2	gnats/database.c
	2	gnats/edit.c
	2	gnats/index.c
	2	gnats/internal.c
	2	gnats/query.c
	1	gnats/client.c
	1	gnats/cmds.c
	1	gnats/gnats.h
	1	gnats/mail.c
	1	gnats/pr-edit.c
	1	gnats/pr-stat.c
	--- basename ---
	2	gnats/queue-pr.c
	1	gnats/gen-closed-date.c
	1	gnats/gen-index.c
	1	gnats/getclose.c
	1	gnats/gnatsd.c
	1	gnats/pr-age.c
	1	gnats/pr-edit.c
	1	gnats/pr-stat.c
	1	gnats/query-pr.c
	--- vasprintf ---
	1	gnats/gnats.h
	1	gnats/internal.c
	--- xmalloc ---
	13	gnats/query.c
	9	gnats/index.c
	7	gnats/pr.c
	6	gnats/field.c
	5	gnats/misc.c
	4	gnats/queue-pr.c
	3	gnats/edit.c
	3	gnats/file-pr.c
	3	gnats/internal.c
	2	gnats/adm.c
	2	gnats/client.c
	2	gnats/gen-closed-date.c
	2	gnats/gnatsd.c
	1	gnats/cmds.c
	1	gnats/database.c
	1	gnats/gen-index.c
	1	gnats/lists.c
	1	gnats/mail.c
	1	gnats/pr-age.c
	1	gnats/pr-edit.c
	1	gnats/pr-stat.c
	--- xrealloc ---
	5	gnats/query.c
	3	gnats/gnatsd.c
	3	gnats/pr.c
	2	gnats/field.c
	2	gnats/index.c
	2	gnats/misc.c
	2	gnats/pr-edit.c
	1	gnats/client.c
	1	gnats/cmds.c
	1	gnats/file-pr.c
	1	gnats/gen-index.c
	1	gnats/mail.c
	1	gnats/queue-pr.c
	--- xstrdup ---
	15	gnats/client.c
	10	gnats/mail.c
	9	gnats/field.c
	8	gnats/cmds.c
	8	gnats/database.c
	8	gnats/file-pr.c
	7	gnats/index.c
	7	gnats/pr.c
	4	gnats/edit.c
	4	gnats/query.c
	3	gnats/adm.c
	1	gnats/gnatsd.c
	1	gnats/internal.c
	1	gnats/pr-edit.c
	1	gnats/queue-pr.c

The dependency of GNATS sources on libiberty functions (functions):
	87	xstrdup
	69	xmalloc
	51	asprintf
	25	xrealloc
	10	basename
	2	vasprintf

The dependency of GNATS sources on libiberty functions (files):
	24	gnats/query.c
	21	gnats/field.c
	21	gnats/pr.c
	20	gnats/file-pr.c
	20	gnats/index.c
	19	gnats/client.c
	15	gnats/queue-pr.c
	13	gnats/mail.c
	11	gnats/cmds.c
	11	gnats/database.c
	10	gnats/misc.c
	9	gnats/edit.c
	7	gnats/gnatsd.c
	7	gnats/internal.c
	6	gnats/pr-edit.c
	6	gnats/query-pr.c
	5	gnats/adm.c
	4	gnats/gnats-pwconv.c
	3	gnats/gen-closed-date.c
	3	gnats/gen-index.c
	3	gnats/pr-stat.c
	2	gnats/gnats.h
	2	gnats/pr-age.c
	1	gnats/getclose.c
	1	gnats/lists.c

A number of libiberty functions in GNATS code: 244

Libiberty functions (used by GNATS / provided): 6 / 42


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gnatsd problems with 4.0.1
  2005-02-07 15:47       ` Mike M. Volokhov
@ 2005-02-07 17:15         ` Mark D. Baushke
  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-07 17:45         ` Chad Walstrom
  1 sibling, 2 replies; 14+ messages in thread
From: Mark D. Baushke @ 2005-02-07 17:15 UTC (permalink / raw)
  To: Mike M. Volokhov; +Cc: help-gnats

Mike M. Volokhov <mishka@apk.od.ua> writes:

> On Thu, 6 Jan 2005 11:04:35 -0600
> Chad Walstrom <chewie@wookimus.net> 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 :ext:anoncvs@savannah.gnu.org/cvsroot/gnulib 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
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Removing libiberty (was Re: gnatsd problems with 4.0.1)
  2005-02-07 15:47       ` Mike M. Volokhov
  2005-02-07 17:15         ` Mark D. Baushke
@ 2005-02-07 17:45         ` Chad Walstrom
  2005-02-09 10:56           ` Mike M. Volokhov
  1 sibling, 1 reply; 14+ messages in thread
From: Chad Walstrom @ 2005-02-07 17:45 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 2257 bytes --]

Mike M. Volokhov wrote:
> First, excuse me please for the delayed answer. :-(

No problem, we're all busy these days.  Work has been hectic and I
haven't been able to provide those two hours per week I had hoped.  By
the end of February, however, this should change and I'll once again be
able to spend more time on GNATS.

> Yes, that's exactly I've asked why. Including libiberty in GNATS
> codebase depends on how much it is used by the project.

Thanks for the audit, by the way.  Very nice work.

> Unfortunately, libiberty itself seems have not official distribution

In addition, there does not seem to be any plans to create an official
library.

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

Again thanks!

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

Actually, add one more: getopt(), which is the one that's currently
giving us problems on the BSD platform.

> Three functions (xstrdup, xmalloc, xrealloc) are totally
> libiberty-own, but can be easy replaced with their standard
> equivalents.

Yes.  They're convenience functions documented in the glibc "standards"
manual as well.  In fact, writing wrapper functions is well documented
by the venerable Stevens in his Unix programming books, although I
believe he would have named the wrapper "Malloc()".  ;-) As such,
they're not bad little functions, but I agree that we shouldn't have to
carry libiberty around just for these three.

> Thus, I propose to eliminate dependency on libiberty completely.

I support that proposal.  When only 7 of 42 are required, they should be
relatively easy to move into misc.c or a utils.{c,h} file pair and
support in autoconf.

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gnatsd problems with 4.0.1
  2005-02-07 17:15         ` Mark D. Baushke
@ 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
  1 sibling, 0 replies; 14+ messages in thread
From: Chad Walstrom @ 2005-02-07 19:17 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 1307 bytes --]

Mark D. Baushke wrote:
> I would suggest consideration of including the GNULIB versions of
> those functions as an alternative.

Cool.  I didn't know this [1]_ existed.

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

We are currently using autoconf, but not automake.  Part of the reason I
updated the libiberty directory in the first place was because of
updating our autoconf version requirements.  Perhaps it's time to push
the move to automake as well.  You mentioned this not too long ago, and
I expressed interest in holding off until 4.2.  I consider cleaning up
the libiberty mess important enough for 4.1, and if automake is required
to do that, then I'd support that move as well.

With tree clean-up in mind, it looks like the makefile stubs in ./config
are pretty much useless now, and have been for at least three years.  We
may as well use that for storing autoconf files, etc.  Additionally,
gnats/man looks out-of-date with respect to doc/man.

.. [1] http://www.gnu.org/software/gnulib/manual/gnulib.html

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Removing libiberty (was Re: gnatsd problems with 4.0.1)
  2005-02-07 17:45         ` Chad Walstrom
@ 2005-02-09 10:56           ` Mike M. Volokhov
       [not found]             ` <20050221235730.GC31157@wookimus.net>
  0 siblings, 1 reply; 14+ messages in thread
From: Mike M. Volokhov @ 2005-02-09 10:56 UTC (permalink / raw)
  To: Chad Walstrom; +Cc: help-gnats

[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]

On Mon, 7 Feb 2005 11:42:01 -0600
Chad Walstrom <chewie@wookimus.net> wrote:

> Mike M. Volokhov wrote:
[snip]
> > 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).
> 
> Actually, add one more: getopt(), which is the one that's currently
> giving us problems on the BSD platform.

What kind of troubles you have? Yes, there is a set of differences, but
I just wish to know a direction to handle them.

> > Three functions (xstrdup, xmalloc, xrealloc) are totally
> > libiberty-own, but can be easy replaced with their standard
> > equivalents.
> 
> Yes.  They're convenience functions documented in the glibc "standards"
> manual as well.  In fact, writing wrapper functions is well documented
> by the venerable Stevens in his Unix programming books, although I
> believe he would have named the wrapper "Malloc()".  ;-) As such,
> they're not bad little functions, but I agree that we shouldn't have to
> carry libiberty around just for these three.
> 
> > Thus, I propose to eliminate dependency on libiberty completely.
> 
> I support that proposal.  When only 7 of 42 are required, they should be
> relatively easy to move into misc.c or a utils.{c,h} file pair and
> support in autoconf.

Exactly. The utils.[ch] possible the best place for handling this small
piece of software. Altough, I have rewrite some functions from scratch
and thus it can be joined the misc.[ch] files.

Please take a look to my patch which eliminates "libiberty" and
"include" directories completely. To test it:

1) Please be sure you have yesterday's AnonCVS sources.
2) Save the attached compressed diff to gnats subdirectory.
3) Apply a patch saved:
	gunzip < gnats-wo-libiberty.diff.gz | patch
4) Rename or remove "libiberty" and "include" subdirectories.
5) Configure and install GNATS as usual.

The following files was changed:

	Makefile.in
	configure
	configure.in
	configure
	gnats/Makefile.in
	gnats/ansidecl.h (moved from include/ansidecl.h)
	gnats/configure
	gnats/configure.in
	gnats/gnats.h
	gnats/util.h (added)
	gnats/util.c (added)
	libiberty/* (all removed)
	include/* (all removed)

The following functions was rewritten from scratch and was based on
their respective standard equivalents:

	xmalloc()
	xrealloc()
	xstrdup()

The following functions should be shipped by 3rd-party vendors and thus
configure will rely on them (yes, I've dropped them from GNATS):

	basename()
	asprintf()
	vasprintf()

The xstrndup() function was changed to more fault-tolerant behaviour,
when passed length is less than 1. This fixes potential problems with
other functions which relies on xstrndup(), i.e.:

	strlen(xstrndup(string, 0))

I did some tests on my NetBSD 2.x and have not any visible troubles.

--
Mishka.


[-- Attachment #2: gnats-wo-libiberty.diff.gz --]
[-- Type: application/octet-stream, Size: 9055 bytes --]

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Removing libiberty (was Re: gnatsd problems with 4.0.1)
  2005-02-07 17:15         ` Mark D. Baushke
  2005-02-07 19:17           ` Chad Walstrom
@ 2005-02-09 12:50           ` Mike M. Volokhov
  2005-02-09 17:15             ` Mark D. Baushke
  1 sibling, 1 reply; 14+ messages in thread
From: Mike M. Volokhov @ 2005-02-09 12:50 UTC (permalink / raw)
  To: Mark D. Baushke; +Cc: help-gnats

On Mon, 07 Feb 2005 09:09:20 -0800
"Mark D. Baushke" <mdb@juniper.net> wrote:

> Mike M. Volokhov <mishka@apk.od.ua> writes:
[snip]
> > 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.

Some libiberty functions, such as getopt, was moved to GNU, BSD and
other C libraries. Many (like some x* ones) are very simple. Please try
a patch (see my another message within "Removing libiberty" topic) which
utilizes many functions from standard libc, shipped with build OS.

Another reason to use libc native to OS, is optimization.

Anyway, as for me, GNULIB is better way than have libiberty in tree.
Thanks for pointing it out!

[snip]
> 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.

Does GNULIB provides the shared library (.so)? If so, there is would no
need to create extra directories in GNATS tree.

--
Mishka.


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Removing libiberty (was Re: gnatsd problems with 4.0.1)
  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
  0 siblings, 0 replies; 14+ messages in thread
From: Mark D. Baushke @ 2005-02-09 17:15 UTC (permalink / raw)
  To: Mike M. Volokhov; +Cc: help-gnats

Mike M. Volokhov <mishka@apk.od.ua> writes:

> On Mon, 07 Feb 2005 09:09:20 -0800
> "Mark D. Baushke" <mdb@juniper.net> wrote:
> 
> > Mike M. Volokhov <mishka@apk.od.ua> writes:
> [snip]
> > > 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.
> 
> Some libiberty functions, such as getopt, was moved to GNU, BSD and
> other C libraries. Many (like some x* ones) are very simple. Please try
> a patch (see my another message within "Removing libiberty" topic) which
> utilizes many functions from standard libc, shipped with build OS.
> 
> Another reason to use libc native to OS, is optimization.

The reason to use GNULIB is consistent functional results. Some of the
GNULIB functions implement full POSIX semantics while the OS version may
not.

> Anyway, as for me, GNULIB is better way than have libiberty in tree.
> Thanks for pointing it out!

You are welcome.

> [snip]
> > 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.
> 
> Does GNULIB provides the shared library (.so)? If so, there is would no
> need to create extra directories in GNATS tree.

No, the GNULIB provides a set of replacement or wrapper functions along
with automake and autoconf glue to put them all together. However, each
separate project that uses the GNULIB will only be using a subset of the
functions and .h files that are available for GNULIB as a whole, so there
is no single .so that has everything in it.

While I suppose that you could create some kind of a libgnats.so that
includes those functions which gnats needs, it would be up to you to
specify things properly in the Makefile.am to do that generation,
possibly in conjuction with libtool
(http://www.gu.org/software/libtool).

	Enjoy!
	-- Mark


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Soon to come: RC3
       [not found]               ` <20050222175714.30bc1593.mishka@apk.od.ua>
@ 2005-02-24 22:17                 ` Chad Walstrom
  2005-02-24 22:40                   ` RC2 (was Re: Soon to come: RC3) Chad Walstrom
  0 siblings, 1 reply; 14+ messages in thread
From: Chad Walstrom @ 2005-02-24 22:17 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 726 bytes --]

Looks like we've had lots of CVS activity today:

    * I removed the gnats/man directory, the contents of the config
      directory, fixed a bug with send-pr manpage installation, and
      updated the texinfo/texinfo.tex file.

    * Mel merged in his first of many patches to abstract database
      access, which included some bugfixes and performance enhancements
      as well.

    * Mike's work to remove libiberty was checked in

So, I suppose it's time to tag this one RC3.  Are there any other
changes you feel we should incorporate before releasing this as 4.1.0?

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RC2 (was Re: Soon to come: RC3)
  2005-02-24 22:17                 ` Soon to come: RC3 Chad Walstrom
@ 2005-02-24 22:40                   ` Chad Walstrom
  0 siblings, 0 replies; 14+ messages in thread
From: Chad Walstrom @ 2005-02-24 22:40 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 355 bytes --]

Chad Walstrom wrote:
> So, I suppose it's time to tag this one RC3.  Are there any other
> changes you feel we should incorporate before releasing this as 4.1.0?

RC2 rather.  The CVS tag will be "gnats-4_1_0-rc2".

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2005-02-24 22:40 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-05 18:23 gnatsd problems with 4.0.1 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
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]             ` <20050221235730.GC31157@wookimus.net>
     [not found]               ` <20050222175714.30bc1593.mishka@apk.od.ua>
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

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