Re: Friendlier gnulib-tool error messages with multiple incompatible modules

GPL > chdir-longGPL > chown GPL > ... > xstrndup GPL > gnulib-tool: *** Stop. > > > 2008-09-25 D

Re: Friendlier gnulib-tool error messages with multiple incompatible modules

Ralf Wildenhues wrote: > * Derek Price wrote on Thu, Sep 25, 2008 at 05:10:31PM CEST: >> --- gnulib-tool revision 1.307 >> +++ gnulib-tool working copy > >> +func_push () >> +{ >> + var=$1 >> + shift >> + for e; do > > The more portable

Re: Friendlier gnulib-tool error messages with multiple incompatible modules

Ralf Wildenhues wrote: > a couple of nits, if I may: The attached patch addresses all of Ralf's nits, fixes a few minor bugs, and contains a few additional simplifications of the new functions. Any objections? Regards, Derek -- Derek R. Price Solutions Architect Ximbiot, LLC

Friendlier gnulib-tool error messages with multiple incompatible modules

Hey all, Anyone mind if I commit the attached patch? It makes `gnulib-tool --update --lgpl' list all incompatible modules instead of breaking after the first one, like so: $ ../gnulib/gnulib-tool --update --lgpl gnulib-tool: *** incompatible license on modules: gnulib-tool: *** areadlink-with-si

Re: FYI: getdelim.c needs SIZE_MAX

Simon Josefsson wrote: >Derek Price <[EMAIL PROTECTED]> writes: > > >>may not be defined. I've installed the attached patch, ripped verbatim >>from serveral other modules. >> >> > >Shouldn't we use the size_max module instead? > &

FYI: getdelim.c needs SIZE_MAX

4-bit hosts with lines longer than 2 GiB. The problem is that the new SSIZE_MAX macro depends on SIZE_MAX, which may not be defined. I've installed the attached patch, ripped verbatim from serveral other modules. 2005-10-05 Derek Price <[EMAIL PROTECTED]> * getdelim.c (SI

Re: mingw32 and sockets

Conrad T. Pino wrote: >I suggest avoiding "wnt_select" in favor of either "wnt_fd_select" or >"woe32_fd_select" instead. > > I prefer woe32_fd_select, but you're writing it and I'm not that picky. :) >Wrapping the Windows Socket API to integrate sockets into the CRT number >space might work b

Re: mingw32 and sockets

Ingolf Steinbach wrote: >I have done a select() emulation on Win32 once. It was horrible. > I don't suppose the implementation was GPL'd or LGPL'd or could be? >And maybe the situation is easier for CVS when the communication >can be reduced to pipes and sockets (e.g. no serial support). > >

Re: mingw32 and sockets

Bruno Haible wrote: >The Woe32 socket API has three main differences w.r.t. the POSIX socket API: > > - The type of a socket is 'SOCKET', not 'int'. A SOCKET cannot be used in >places where a file descriptor is used. This means in particular that >close(), select(), poll() don't work on s

Re: regex workaround for gcc 2.95.3 core dump

Paul, This is the same problem I ran into a few days ago on several platforms, and you helped me come up with this patch: . The patch in that message also removes a little cruft and handles a similar problem in a later GCC with a

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Paul Eggert wrote: >Derek Price <[EMAIL PROTECTED]> writes: > > > >><http://lists.gnu.org/archive/html/bug-gnulib/2005-09/msg00055.html>. >> >> > >Bruno doesn't like AC_LIBSOURCES so I doubt whether he'll accept that >part of t

regcomp.c Windows warning

At least on Windows, where I guess strcasecmp is not declared in , compiling regex.c elicits the following warning: lib\regcomp.c(852) : warning C4013: 'strcasecmp' undefined; assuming extern returning int I assume that, since "strcase.h" provides a prototype for strcasecmp, other systems have

FYI: Remove unneeded include from getaddrinfo.c

was already #included via getaddrinfo.h: 2005-09-20 Derek Price <[EMAIL PROTECTED]> * getaddrinfo.c: Don't include included from getaddrinfo.h. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6168 f: +1 717

mbuiter.h & mbsinit (new mbsinit module?)

mbuiter.h makes the unportable assumption that mbsinit() is a working function. Since it looks at first glance like mbiter.h has the same problem, I wasn't sure whether adding AC_CHECK_FUNCS_ONCE(mbsinit) to m4/mbiter.m4 and any other m4 macros for modules which use mbsinit(), plus the following c

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Yoann Vandoorselaere wrote: >The mail you're pointing out is the patch I sent :-) >My question is rather whether it will be applied to the GnuLib CVS >version. > > Er, that's what I meant. :) I did apply and test it on several systems here, however, and it is working. :) Derek -- Derek R.

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Excuse me, I misspoke - the patch has been working on half a dozen systems for some weeks in nightly testing. I just finally got the other dozen or so systems up only a few days ago, but it's been compiling & testing ok there since they came up. Regards, Derek Derek Price wrote

Re: regex_internal.h modification lead to GCC crash

Paul Eggert wrote: >How about if we do this instead? The basic idea is to shut off >__attribute__ entirely for GCC before 3.1. There's little point to > > This patch works fine on BSD 1.6.1, one of the offending systems and I expect it will work fine on the rest. I've installed it in CVS CVS

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Yoann Vandoorselaere wrote: >Bruno, is there any update concerning this issue ? >GnuLib CVS has not being fixed, and this problem break the compile on a >number of systems. > > I sent in a patch for this previously: . This pa

Re: regex_internal.h modification lead to GCC crash

I've tested it on two of the offending platforms. 2005-09-19 Derek Price <[EMAIL PROTECTED]> * regex_internal.h (attribute_always_inline, attribute_pure): Instead of blanking pure and always_inline when not available, define new macros. Use attribute_pure as needed for f

Re: [bug-gnulib] gnulib-tool --import slowness

Bruno Haible wrote: >Derek Price wrote: > > >>The --tests-base option is no longer defaulting to "tests" as >>`gnulib-tool --help' specifies, however: >> >>gnulib-tool: *** missing --tests-base option >>gnulib-tool: *** Stop. >>

Re: [bug-gnulib] gnulib-tool --import slowness

Bruno Haible wrote: >Derek Price wrote: > > >>$ time maint-aux/gnulib-update >> >>real14m42.968s >>user3m45.188s >>sys 10m41.704s >>$ >> >>Just a few weeks back, I think it was taking a minute or three to run >> >

FYI: GNULIB glob-libc.h path in srclist.txt

2005-09-19 Derek Price <[EMAIL PROTECTED]> * srclist.txt: glibc's glob.h is now in lib/glob-libc.h. Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6168 f: +1 717.234.3125 <mailto:[EMAIL PROTECTED]> 2005-09-1

Re: getaddrinfo module broken

With my autoconf 2.59, the call to AC_REPLACE_FUNCS(getaddrinfo gai_strerror) in gl_GETADDRINFO calls AC_CHECK_FUNCS(getaddrinfo gai_strerror), which defines HAVE_GETADDRINFO when getaddrinfo is found (and HAVE_GAI_STRERROR, similarly...). I would look to make sure gl_GETADDRINFO is being called a

Re: gnulib features.h?

Paul Eggert wrote: >Other than that, it looks good. As I understand it, you want the >following change from a day ago. This is pretty simple. > > Yes. I've installed this. I've not attached a patch since you effectively sent it out in your last email. 2005-09-15

Re: gnulib features.h?

liberty of replacing two #if __GNUC__ >= constructs in regex_internal.h with __GNUC_PREREQ calls. 2005-09-15 Derek Price <[EMAIL PROTECTED]> * regcomp.c, regexec.c, regex_internal.c: Back out previous changes, consolidating in... * regex_internal.h: ...this file. Replace t

Re: gnulib features.h? (was regex warnings)

Paul Eggert wrote: >I'd fix it if I were you. You can use the __GNUC_PREREQ macro of >md5.h. > > I know I've already installed this fix but, for future reference, is there a simple reference I could use to find what version of GCC an attribute first appeared in? Something easier than fumbling

Re: gnulib features.h? (was regex warnings)

and used it, except in regex_internal.h, where I stumbled across a convenient #if __GNUC__ <= 3 switch already being used to protect usage of inline, and used that. 2005-09-15 Derek Price <[EMAIL PROTECTED]> * regex_internal.h: Blank `pure' for GNUC < 3.

regex warnings

I'm seeing "warning: `pure' attribute directive ignored" warnings from regex_internal.h & regex_internal.c compiling with GCC 2.95.4 on Alpha Linux 2.2.20. Similarly, I see "warning: `always_inline' attribute directive ignored" warnings compiling regcomp.c & regexec.c. Is this something worth wor

Re: [bug-gnulib] strstr redefinition fix

Bruno Haible wrote: >Thanks. I applied the appended patch, very similar to yours. (But move >the #include outside the extern "C" { ... }.) > > Any reason why you left this inside? + #undef strstr + #define strstr rpl_strstr Just because it didn't matter? Thanks, Derek -- Derek R. Price

Re: [bug-gnulib] Incomplete getaddrinfo module

ttached patch, but perhaps a shorter note in the modules file like, "* Incomplete - see lib/getaddrinfo.c." would be better. The extra notes my patch adds to modules/getaddrinfo could then be added to lib/getaddrinfo.c, then, but I think they would be superfluous. 2005-09-15 Der

strstr redefinition fix

ightly/lib/strstr.c:46: parse error before `.' ...and so on. It looks like a pretty straightforward case of the strstr definintion in string.h overwriting the one required by the strstr module. The attached untested patch should fix this: 2005-09-15 Derek Price <[EMAIL PROTECTED]>

Re: [bug-gnulib] Incomplete getaddrinfo module

Yoann Vandoorselaere wrote: >>> if (hints && (hints->ai_flags & ~AI_CANONNAME)) >>>/* FIXME: Support more flags. */ >>>return EAI_BADFLAGS; >>> >>> >>If you say which flags your application needs to work, maybe Simon can >>do something about it? >> >> > >For my own use, I simply

Re: gnulib update (Tue Sep 13 09:03:01 EDT 2005)

Jim Meyering wrote: >Personally, I've found it useful enough to have consistently cpp-indented > > I like it too, but I was willing to go with the flow on GNULIB. :) >sources that I wrote cppi, and to use it in a commit-hook for the coreutils. > > I don't know when it became an option, but

Re: gnulib update (Tue Sep 13 09:03:01 EDT 2005)

Jim, all, Is there a GNULIB standard for this yet? Paul Eggert just went through my glob_.h and tweaked the cpp spacing in the other direction. I assumed at the time this meant that double-include protection should be ignored for the purposes of indenting compiler directives in headers, but Jim

Re: [bug-gnulib] Re: mmapping of /dev/zero always fails on darwin

Peter O'Gorman wrote: > Peter O'Gorman wrote: > >> Looks like the cvs folks need to update their gnulib. > > > Of course, they have done this, and I feel silly. Yes, they have. :) That fix should be released with 1.12.13, which shouldn't be very far away. Regards, Derek -- Derek R. Price C

Re: canon-host errors

Jim Meyering wrote: >Derek Price <[EMAIL PROTECTED]> wrote: > > >>I've installed the attached patch. It is almost identical to my >>previous one, with a few extra portability and typo fixes. >> >>2005-09-12 Derek Price <[EMAIL PROTECTED]&g

Re: canon-host errors

I've installed the attached patch. It is almost identical to my previous one, with a few extra portability and typo fixes. 2005-09-12 Derek Price <[EMAIL PROTECTED]> * modules/canon-host: Add canon-host.h. Depend on getaddrinfo. Make LGPL. * modules/getaddrinfo:

Re: glob_.h & glibc

Okay, I've committed the glob-min-glibc-h-changes2.diff patch. The glob.h-glibc-to-gnulib2.diff should be the new minimal patch for submission to glibc. 2005-09-12 Derek Price <[EMAIL PROTECTED]> Paul Eggert <[EMAIL PROTECTED]> * modules/glob (Files)

Re: mmapping of /dev/zero always fails on darwin

Peter O'Gorman wrote: > The test would have to be a run test, which would mean having a > cross-compile alternative switching on the system name (this is why > gcc switches on name). All, Generally, I choose to be pessimistic about test failures when cross-compiling. Anyone have an opinion abo

Re: mmapping of /dev/zero always fails on darwin

Peter O'Gorman wrote: > As you can see from this little snippet of gcc configure, you can't > mmap /dev/zero on darwin. > >AC_CACHE_CHECK([whether mmap from /dev/zero works], > gcc_cv_func_mmap_dev_zero, > [# Add a system to this blacklist if it has mmap() but /dev/zero ># does not exi

FYI: gai_strerror.h needs config.h

I've committed the attached patch. gai_strerror.c was breaking on the #include of getaddrinfo.h because `restrict' was not defined properly on HP-UX 11.00. 2005-09-12 Derek Price <[EMAIL PROTECTED]> * gai_strerror.c: Include config.h when available. Include

Re: glob_.h & glibc

Paul Eggert wrote: >OK, but in that case shouldn't the AC_REQUIRE([AC_GNU_SOURCE]) be in >gl_GLOB rather than gl_PREREQ_GLOB? > > I don't think so. gl_GLOB tests for the _GNU_GLOB_INTERFACE_VERSION macro from & a known bug in GNU glob's POSIX support. Neither requires the GNU extensions enab

Re: glob_.h & glibc

Paul Eggert wrote: >I assume you fixed this by removing the AC_REQUIRE([AC_GNU_SOURCE]) >from glob.m4 and restoring the condtional #define __USE_GNU 1 to >glob_.h? If it's more complicated than that, please let me know. > > No, this is exactly what I did, except I forgot to remove the AC_REQUI

Re: glob_.h & glibc

Paul Eggert wrote: >Thanks. A few comments. First, that SYS_CDEFS_H thing is really > > This all looks good, except: >Fourth, we can AC_REQUIRE AC_GNU_SOURCE, so that we needn't worry about >__USE_GNU. > > We ran into this problem the first time we went through this:

Re: glob_.h & glibc

Paul Eggert wrote: >Hmm, actually they provisionally accepted the bug-1060 changes except >for the part about using prototypes when defining external functions. > > Oh, that's what that meant. I was hoping someone else would say something if it was important. Thanks. :) >where glob-libc.h i

Re: glob_.h & glibc

It's late, I'm tired. Patches actually attached now. 2005-09-08 Derek Price <[EMAIL PROTECTED]> * m4/glob.m4 (gl_GLOB_SUBSTITUTE): AC_LIBSOURCE C files. * lib/glob_.h: Move most code forked from glibc here, then include... * lib/glob-glibc.h: ...this new fi

Re: AC 2.59 incompatibility in getaddrinfo.h

Paul Eggert wrote: >>shortening the above test to: "# if !HAVE_GETADDRINFO", and I'd >>rather just simplify the header >> >> > >Yes, that sounds right. > > Okay, thanks, Paul. I've committed this to CVS CVS for more testing before I finish importing it into GNULIB. Cheers, Derek -- Der

glob_.h & glibc

Re: , glibc objected to the extent of our changes to an installed header (glob.h) to bring the file into sync with GNULIB. (They did accept the glob.c changes, though they have yet to apply them.) It is true, as Roland says, that we could put mo

AC 2.59 incompatibility in getaddrinfo.h (was Re: canon-host errors)

Is there any reason I can't just assume gl_GETADDRINFO ran and config.h was included before getaddrinfo.h? The following test is always coming up false on platforms without getaddrinfo (as of AC 2.59, at least, AC_CHECK_FUNCS via AC_REPLACE_FUNCS leaves HAVE_GETADDRINFO undefined when it is not fo

Re: improve regex bitset performance (don't assume 32 bits)

Derek Price wrote: >Oh, no, sorry. I'm accessing a Linux host via a Cygwin xterm. Some >sort of term incompatibility causes almost everything quoted in all >program output (I assume with a backticks-singlequote combination, >though that's from memory and I haven

Re: improve regex bitset performance (don't assume 32 bits)

Paul Eggert wrote: >By the way, did GCC really say "In function â"? That is, an "a" with >a circumflex over it? If so, should this be a GCC bug that we should >be worrying about? > > Oh, no, sorry. I'm accessing a Linux host via a Cygwin xterm. Some sort of term incompatibility causes almos

Re: improve regex bitset performance (don't assume 32 bits)

Paul Eggert wrote: >Thanks for reporting that. I installed this patch and updated the glibc >bug report. > > Thanks! Derek -- Derek R. Price CVS Solutions Architect Ximbiot v: +1 717.579.6168 f: +1 717.234.3125

Re: improve regex bitset performance (don't assume 32 bits)

The latest regex issues this warning with -Wall: In file included from regex.c:55: regex_internal.h: In function â: regex_internal.h:837: warning: suggest parentheses around + or - in operand of & rm -f libcvs.a Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot

Re: [bug-gnulib] gnulib-tool --import slowness

Bruno Haible wrote: >files. I'll change this to use "join" and "sort" instead of a double loop. > > Did you do this? I'm still getting pretty slow operation with CVS: $ time maint-aux/gnulib-update real14m42.968s user3m45.188s sys 10m41.704s $ Just a few weeks back, I think it w

getpass.c syntax error on HP-UX 11.00

Is the following line in lib/getpass.c correct? #if TCSETATTR A similar reference earlier uses `HAVE_TCGETATTR' for the get counterpart to set. Also, there are no tests that I see which set either macro and attempting to compile on HP-UX 11.00 yields the following error message: DEPDIR=.dep

Re: canon-host errors

getaddrinfo when it was present - the documentation on gethostbyname also implied that the hostname would be resolved and a test program on 1 linux & NetBSD 1.6.1 showed that it was. If we stumble across any systems where gethostbyname returns an IP address when it is given a real ho

Re: [PATCH] Re: wctype.h and wchar.h inclusion

Yoann Vandoorselaere wrote: >On Thu, 2005-09-01 at 12:28 +0200, Yoann Vandoorselaere wrote: > > >>Hi, >> >>An OpenBSD Prelude user reported that GnuLib will fail to compile on >>OpenBSD 3.7 due to the new dependencies of modules like strcase on >>wctype.h and wchar.h headers. >> >> I've go

Re: canon-host errors

Hrm. The POSIX getaddrinfo specification is pretty clear about *not* resolving a name for ai_canonname if name is in IP dot notation, yet sometimes the canon-host implemetation does a reverse-lookup to get a canonical name (for some odd condition where gethostbyname fills in the h_name field of th

Re: canon-host errors

Derek Price wrote: >This was about what I was thinking, though I was going to combine >canon_host & canon_host_r in the canon-host module and let the caller >decide what to call. How about this API: > > Hrm. Why isn't canon-host dependant on getaddrinfo? It would

Re: canon-host errors

Derek Price wrote: >Hrm. Why isn't canon-host dependant on getaddrinfo? It would > The alternative is that the ch_strerror_r function I've been working on would need to handle ENOMEM too, which introduces a dependency on strerror_r... I almost have the previously discussed

Re: canon-host errors

Jim Meyering wrote: >I don't thinks it's worthwhile to pander to single-threaded >applications for something like this. > > In this case, pandering isn't very complicated, so I think I'll do it. Besides, this way, if anyone else is using the canon-host module, they won't need to update callers

FYI: gnulib-tool reverse --symlink logic fix

2005-09-04 Derek Price <[EMAIL PROTECTED]> * gnulib-tool: Fix reversed $symbolic logic. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6168 f: +1 717.234.3125 <mailto:[EMAIL PROTECTED]>

Re: canon-host errors

Jim Meyering wrote: >I like your idea of keeping them separate. >How about passing either NULL or the address of a struct >containing a member for each error indicator? > > Okay. Will do. Should I ignore single-threaded apps entirely, keep the error data in a global to simplify for single-thr

Re: canon-host errors

Jim Meyering wrote: >Personally, I don't mind if you add the code to emit warnings now, >as long as you agree to adjust the API later, (e.g., to add >a new enum parameter describing the error) if anyone complains. >Of course, it'd be better to keep it library-safe. > > Hrm. A new enum paramete

canon-host errors

Hi all, Would anyone object to a patch that caused canon-host to output warnings via error (0, ...) when one of the functions it calls fails? getaddrinfo returns errors differently than gethostbyname and gethostbyaddr, making outputting a useful error message upon seeing a simple NULL return from

FYI: fix for getlogin_r.m4 cut & paste error

Committed patch attached. 2005-07-03 Derek Price <[EMAIL PROTECTED]> * getlogin_r (gl_GETLOGIN_R): Fix cut & paste error. From Larry Jones <[EMAIL PROTECTED]>. Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6

Re: getdelim doesn't set errno on failure?

Patch actually attached this time. Regards, Derek Derek Price wrote: >Oskar Liljeblad wrote: > > > >>Well, the current Gnulib implementation doesn't behave that way. >>It will return 0 if the first call to getc fails (for whatever reason - >>error or E

Re: getdelim doesn't set errno on failure?

ich was prevoiusly looping indefinitely around code that expected (and has expected for years) a -1 return to signify EOF. 2005-08-31 Derek Price <[EMAIL PROTECTED]> * getdelim.c (getdelim): Return EOF on EOF. Reported by Larry Jones <[EMAIL PROTECTED]>. Regards, D

Re: xvasprintf: don't depend directly on xalloc-die

Simon Josefsson wrote: >Sorry, it seems the xalloc-die logic has changed, so my patch may be >wrong. Specifically: > >2005-07-15 Paul Eggert <[EMAIL PROTECTED]> > > * modules/xalloc (Depends-on): Add xalloc-die. > * modules/xvasprintf (Depends-on): Add xalloc-die. > >I can't find th

Re: FYI: removing HAVE_FCNTL_H tests

Jim Meyering wrote: >Bruno Haible <[EMAIL PROTECTED]> wrote: > > > >>One platform still does not have : It's Woe32 with the MSVC >>compiler. It's unfortunately a major platform, and still alive. >> >> > >Perhaps it's not a popular enough build environment for packages using >gnulib. Several

Re: CVS problem with ssh

Richard M. Stallman wrote: >If the problem occurs with fflush, most likely it will also occur >with fwrite, fclose, etc. fflush is merely the guinea pig here. > >We may have to send bug reports for the systems where it does not always work. > > Agreed. A failed retry in this case is n

Re: Test for glob symlink bug

Paul Eggert wrote: >Derek Price <[EMAIL PROTECTED]> writes: > > > >>I didn't update the serial number. What's the procedure for macro >>serial number updates? >> >> > >It's done by hand. I just did it for glob.m4 so you needn

Re: Test for glob symlink bug

Paul Eggert wrote: >Other than that, it looks fine; please install. > > Attached patch installed. I didn't update the serial number. What's the procedure for macro serial number updates? Regards, Derek Index: m4/glob.m4 === RCS

Re: Test for glob symlink bug

Sorry about the missing patch. Attached. Derek Derek Price wrote: >The attached patch tests for the glibc glob symlink bug and uses the >GNULIB glob module when it is found. It also uses the autoconf cache >more. It tests out on a platform with and without the bug. I'll comm

Test for glob symlink bug

The attached patch tests for the glibc glob symlink bug and uses the GNULIB glob module when it is found. It also uses the autoconf cache more. It tests out on a platform with and without the bug. I'll commit it soon if there are no comments. 2005-07-13 Derek Price <[EMAIL P

Re: CVS problem with ssh

Hi bug-gnulib, I'd like to reopen a discussion on this list from last September: . At the end of that discussion I didn't create the blocking-io module due mostly to Paul Eggert's objections (and a lack of time on my part, espec

Re: check_version

Simon Josefsson wrote: >No particular reason. VERSION is defined automatically by AC_INIT >too, is it not? Is there a difference between PACKAGE_VERSION and >VERSION? I'd be happy to change, it doesn't matter for me. > > The CVS config.h is only showing `PACKAGE_VERSION'. Regards, Derek

Re: check_version

Simon Josefsson wrote: >Ok, unless someone suggests otherwise, I'll change it to >PACKAGE_VERSION later tonight. Perhaps it is Automake that define >VERSION. > > The CVS project uses Automake 1.9.5 and Autoconf 2.59 and VERSION does not get defined. We might not be using a macro that defines

Re: check_version

Simon Josefsson wrote: >+ if (!req_version || strverscmp (req_version, VERSION) < 0) >+return VERSION; > > Why did you choose to call the version string "VERSION" rather than using the "PACKAGE_VERSION" string automatically defined by AC_INIT? Regards, Derek __

Re: stat and lstat should define their replacements

Paul Eggert wrote: >Please install it in gnulib; it looks good to me. Thanks for >following up on it. > > Done: 2005-06-24 Derek Price <[EMAIL PROTECTED]> and Bruno Haible <[EMAIL PROTECTED]> Remove stat module & update lstat. * MO

FYI: Declare YACC & YFLAGS precious in m4/bison.m4

This brings bison.m4 closer to what CVS is using. Bruno approved the YFLAGS change way back here: <http://lists.gnu.org/archive/html/bug-autoconf/2004-05/msg00010.html> and no one objected to my YACC correction in the following message. 2005-06-15 Derek Price <[EMAIL

Re: stat and lstat should define their replacements

Derek Price wrote: >I've attached a revised patch. In addition to integrating the >suggestions Bruno's patch received, it also includes changes to >modules/lstat, config/srclist.txt, and MODULES.html.sh. In addition to >this patch, lib/stat.c, m4/stat.m4, and modules/s

Re: gcc -Wall warning for minmax.h

Paul Eggert wrote: >I'm not sure about the documentation change. It's not yet clear to me >that we want to document AS_LITERAL_IF (the above example being one of >the gotchas). If we do want to document it we probably need to be >more systematic about it and its friends. So I left that alone fo

Re: gcc -Wall warning for minmax.h

Stepan Kasal wrote: >After that fix, we could also remove the AS_LITERAL_IF with m4_fatal. > > I'm not sure what you were referring to here so I've attached a patch to document AS_LITERAL_IF as you requested a few days ago. I will commit it in a few days if there are no objections. It looks l

FYI: M4 macro documentation (was Re: gcc -Wall warning for minmax.h)

Derek Price wrote: >Would anyone mind if I committed a patch with @msindex entries for the >37 or so undocumented m4_* macros in the `Redefined M4 Macros' node of >doc/autoconf.texi? I'm not bothering to include the patch in this email >because it is too simple but I don&

FYI: Minor patch to glob_.h

I've installed the attached patch: 2005-06-07 Derek Price <[EMAIL PROTECTED]> Sync from CVS. * lib/glob_.h: Indent nested #ifdef. Do you want me to keep sending FYI's to this list for this sort of minor change? Regards, Derek In

Re: stat and lstat should define their replacements

Paul Eggert wrote: >Derek Price <[EMAIL PROTECTED]> writes: > > > >>What does this mean for Bruno's recent patch for stat & lstat which >>removed the SunOS 4.1.4 support in addition to some other fixes? >> >> > >His patch made sense

Re: gcc -Wall warning for minmax.h

Stepan Kasal wrote: >- We need to document also AS_LITERAL_IF and m4_fatal > (And you could also document m4_warning, when you are at it.) > > I'll see about it after I get comments on the first round back. >- we have to document also the fact that AS_TR_SH & AS_TR_CPP expand > to literal va

Re: [bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

Paul Eggert wrote: >I wouldn't object to minor and obvious tweaks that are checked out by >a real user who actually needs findutils to run on SunOS 4.1.4. My >assumption in dropping support for SunOS 4.1.4 was partly predicated >on nobody really needing it any more (and computer museums don't cou

Re: gcc -Wall warning for minmax.h

Bruno Haible wrote: >But AS_TR_* is actually undocumented, right? > > Yes, AS_TR_SH & AS_TR_CPP appear to be undocumented. I've submitted a patch to autoconf-patches to remedy this and will commit it within a few days unless there are objections there. Cheers, Derek __

Re: gcc -Wall warning for minmax.h

Bruno Haible wrote: >I blindly searched for m4_pushdef in the manual and didn't find >it. (May I suggest that these renamed m4_* macros be added to the manual's >index, one by one?) > > Autoconf folks: Would anyone mind if I committed a patch with @msindex entries for the 37 or so undocumented

Re: [bug-gnulib] Re: gcc -Wall warning for minmax.h

Bruno Haible wrote: >>- use m4_pushdef/m4_popdef instead of define/undefine >>- use AS_TR_* instead of raw m4_translit >> >> > >m4_pushdef, m4_popdef, AS_TR_* are not documented in the autoconf manual >(latest release, 2.59). In consequence, their meaning can change, or they >can go away entir

Re: [bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

Bruno Haible wrote: >James Youngman wrote: > > >>Certainly I believe that should >>define NULL (though my copy of the standard isn't to hand). >> >> > >On SunOS 4, it doesn't. GNU gettext has this ChangeLog entry: > >2001-10-31 Bruno Haible <[EMAIL PROTECTED]> > >* plural.y: Inclu

Re: [bug-gnulib] Re: inadvertent bison.m4 patch to gnulib?

Karl Berry wrote: >Is there a mailing list for CVS commit messages to GNULIB? > >Yes. Do you want to be on it? > > Yes, please. Regards, Derek ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

[bug-gnulib] Re: inadvertent bison.m4 patch to gnulib?

Paul Eggert wrote: >The following patch was installed on gnulib but it looks inadvertent. >I assume it's OK for me to revert it? Or perhaps you could revert it. > > I reverted it. Sorry about that. I've been maintaining that fork for some time so that more users can compile CVS, even with mu

Re: [bug-gnulib] New GNULIB glob module?

Paul Eggert wrote: >Derek Price <[EMAIL PROTECTED]> writes: > > > >> 1. Corrects an incorrect check for a successful return from >> getlogin_r to assume only 0 means success, per the POSIX2 spec: >> >> <http://www.opengroup.org/o

Re: [bug-gnulib] New GNULIB glob module?

Paul Eggert wrote: >Derek Price <[EMAIL PROTECTED]> writes: > > >>submission part. Perhaps it would be smoother if someone already known >>to the glibc team introduced me and this patch? >> >> > >Yes, probably. I'm willing to have a go

Re: [bug-gnulib] New GNULIB glob module?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >breaks the Windows build since Microsoft does NOT provide "sys/cdefs.h" >implementation. Yes. Since we don't run configure on Windows, _SYS_CDEFS_H needed to be defined to 1 in the windows-NT/config.h.in.in. I've done so and

Re: [bug-gnulib] New GNULIB glob module?

Paul Eggert wrote: >Derek Price <[EMAIL PROTECTED]> writes: > > > >>Fair enough, but why undo the change to glob.m4? Shouldn't I just >>change the target of the AC_DEFINE from MISSING_SYS_CDEFS_H to _SYS_CDEFS_H? >> >> > >Yes, you&#

[bug-gnulib] Re: stat and lstat should define their replacements

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: >! #include This is no longer necessary. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCl4U4LD1OTBfyMaQRAtHxAKCfWXjmMflLt

  1   2   >