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