Hello Karl, Paul,
* Karl Berry wrote on Tue, Aug 29, 2006 at 01:33:14AM CEST:
> why does gnulib/config/srclist.txt list these files as GPL, as do
> the gnulib file headers, but modules/argz says LGPL, and libltdl is
> distributed with LGPL + special exception?
>
> I don't recall any d
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Before syncinc argz* with gnulib: why does gnulib/config/srclist.txt
> list these files as GPL, as do the gnulib file headers, but modules/argz
> says LGPL, and libltdl is distributed with LGPL + special exception?
For the same reason libc files are l
why does gnulib/config/srclist.txt list these files as GPL, as do
the gnulib file headers, but modules/argz says LGPL, and libltdl is
distributed with LGPL + special exception?
I don't recall any deep reasoning behind the gpl in srclist.txt for
these. Probably just blindly copied? So
Bruno Haible <[EMAIL PROTECTED]> writes:
> So it appears that O_NOFOLLOW exists but has no effect.
> Shouldn't be too hard to write a configure against it.
OK, I installed this into gnulib to address the gnulib part of the
problem. I'll send the coreutils changes via another email.
2006-08-28
Bruno Haible clisp.org> writes:
> --- gnulib-20060823-modified/m4/inttypes.m4 2006-07-27 03:12:58.0
+0200
...
> + #ifdef INT32_MAX
> + PRId32 PRIi32
> + #endif
> + #ifdef UINT32_MAX
> + PRIo32 PRIu32 PRIx32 PRIX32
> + #ifdef INT64_MAX
> + PRId64 PRIi64
> + #endif
Oops - missing
Bruno Haible <[EMAIL PROTECTED]> writes:
> If our replacement includes simply , not
> @ABSOLUTE_INTTYPES_H@, then a simple
> #include
> will do the wrong thing: It will
>
>- start including our stdint.h,
>- include the system's stdint.h,
>- start including our inttypes.h,
>
Bruno Haible <[EMAIL PROTECTED]> writes:
> This patch adds an option --makefile-name that does this.
Thanks for doing that. I plan to change coreutils to use it. But
first, I found a problem when gnulib-tool is invoked without
--makefile-name, as the makefile name defaulted to the empty string
Thanks for doing that.
Bootstrapping coreutils found one minor glitch: inttypes now relies on
gl_HEADER_INTTYPES_H indirectly via gt_INTTYPES_PRI but doesn't list
the file containing it. I installed the following obvious patch.
While we're on the subject we should remove gl_HEADER_INTTYPES_H.
Au
Eric Blake wrote:
> One more issue - when the replacement is needed,
> inttypes-pri.m4 AC_SUBST's PRI_MACROS_BROKEN as the empty string when they
> work, rather than defining it to 0; which resulted in lots of preprocessor
> compilation errors:
>
> make[2]: Entering directory `/home/eblake/tar/
> However, on MinGW all three tests fail because the program outputs CRLF
> line endings, while the test suite creates files with LF ending.
Um, why? That is, why does cat>foo produce LF files while hello>foo
produces CRLF files?
Is this different in MinGW than under Cygwin? (I'm probab
Bruno Haible clisp.org> writes:
> Oops. I missed the fact that the PRI* and SCN* macros are not symmetric.
> SCNX* makes no sense (as you can parse hexadecimal numbers without knowing
> in advance whether to look for uppercase or lowercase hexadecimal digits).
> I remove the SCNX* from the inttyp
Eric Blake wrote:
> Cygwin is currently failing the inttypes check because it does not provide
> SCNX8, among others. POSIX does not require the existence of SCNX*, so
> cygwin
> does not provide them.
Oops. I missed the fact that the PRI* and SCN* macros are not symmetric.
SCNX* makes no sens
Bruno Haible clisp.org> writes:
> --- gnulib-20060823-modified/m4/inttypes.m4 2006-07-27 03:12:58.0
+0200
...
> + const char *l = /* implicit string concatenation */
> + #ifdef INT8_MAX
> + SCNd8 SCNi8
> + #endif
> + #ifdef UINT8_MAX
> + SCNo8 SCNu8 SCNx8 SCNX8
Cygwin is currently
Eric Blake wrote:
> Committing this obvious fix:
>
> 2006-08-28 Eric Blake <[EMAIL PROTECTED]>
>
> * modules/inttypes (Depends-on): Fix sed error when inttypes.h
> needs wrapper.
Thanks. Of course.
Bruno
Bruno Haible <[EMAIL PROTECTED]> writes:
>> The problem in automake that would had to be fixed was this:
>>
>> http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/1659
>>
>> Briefly, the gnulib Makefile.am snippet uses += to add contents to
>> variables, such as EXTRA_DIST, which are also
Yoann Vandoorselaere wrote:
> Look good to me.
OK, the patch has been applied.
Bruno
[ no need to discuss this on libtool rather than -patches ]
* Eric Blake wrote on Mon, Aug 28, 2006 at 02:55:21PM CEST:
> According to Paul Eggert on 8/26/2006 12:43 AM:
> >
> > The basic idea is that source files should include config.h
> > unconditionally, so that we needn't clutter "make" outp
Simon Josefsson wrote:
> > This patch adds an option --makefile-name that does this.
>
> I mentioned that approach earlier in:
>
> http://article.gmane.org/gmane.comp.lib.gnulib.bugs/1969
Sorry, I missed or forgot that.
> The problem in automake that would had to be fixed was this:
>
> http://
Bruno Haible clisp.org> writes:
>
> So here's the patch I'm committing.
>
> 2006-08-26 Bruno Haible clisp.org>
>
> * modules/inttypes (Files): Add lib/inttypes_.h, remove lib/inttypes.h.
> Add m4/inttypes.m4, remove m4/_inttypes_h.m4 and m4/include_next.m4.
> (Makefile.am)
Bruno Haible <[EMAIL PROTECTED]> writes:
> While doing the coreutils changes, Paul found the answer to the long-standing
> question how gnulib-tool could be used without requiring a lib/ directory of
> its own and while still maintaining a clear separation between hand-maintained
> files and autog
Paul Eggert wrote:
> 2006-08-23 Paul Eggert <[EMAIL PROTECTED]>
>
> * src/stat.c (HAVE_STRUCT_STATXFS_F_FSID___VAL): Define. This
> macro was being used without being defined.
Compiling the current coreutils CVS on MacOS X 10.3.9 now gives this error:
stat.c: In function `print_st
While doing the coreutils changes, Paul found the answer to the long-standing
question how gnulib-tool could be used without requiring a lib/ directory of
its own and while still maintaining a clear separation between hand-maintained
files and autogenerated files. Namely, rename the gnulib Makefile
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hello Simon,
>
>> Except that I have to specify --local-dir every time I use --import.
>> Is this the intended behaviour? Maybe the --local-dir value could be
>> cached, just like --source-base etc. What do you think?
>
> You're right, it's cumbersome f
Mostly comment updates.
2006-08-27 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_get_tests_module): Don't assume that $gnulib_dir
is the current directory. Respect also $local_gnulib_dir.
*** gnulib-20060823/gnulib-tool 2006-08-27 01:48:40.0 +0200
--- gnulib-2006
Hello Simon,
> Except that I have to specify --local-dir every time I use --import.
> Is this the intended behaviour? Maybe the --local-dir value could be
> cached, just like --source-base etc. What do you think?
You're right, it's cumbersome for --import. Also, --update would not do
the right
This makes for a better error handling during "patch".
2006-08-26 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_verify_module): Check against misapplying patch.
*** gnulib-20060823/gnulib-tool 2006-08-24 03:52:14.0 +0200
--- gnulib-20060823-modified/gnulib-tool20
On Mon, 2006-08-28 at 14:54 +0200, Bruno Haible wrote:
> Hi,
>
> Paul Eggert noted that vasnprintf should be able to return strings of length
> > INT_MAX. Here's a patch to that effect.
>
> Yoann, is the vsnprintf.c patch OK with you? It corresponds to Paul's fixes
> to snprintf.c a week ago.
Hi
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> > The reason is that BeOS does not have PF_INET, only AF_INET, but usually
>> > they
>> > have the same values. Also it doesn't have PF_UNSPEC.
>>
>> Does it AF_UNSPEC? Did you grep the entire /usr/include tree to find
>> PF_I
Simon Josefsson wrote:
> > The reason is that BeOS does not have PF_INET, only AF_INET, but usually
> > they
> > have the same values. Also it doesn't have PF_UNSPEC.
>
> Does it AF_UNSPEC? Did you grep the entire /usr/include tree to find
> PF_INET or PF_UNSPEC? Maybe they are in some non-stan
Eric Blake wrote:
> Paul's latest updates to module dependencies pulled in several .m4 files
> that trigger gcc compiler warnings, breaking the configuration of m4 with
> '-Werror' where it had previously been working. Paul, Bruno, are these
> okay to install?
I installed the remaining patch to c
Paul Eggert wrote:
> > But it's important to know that c_strstr (s, "x") is not safe and
> > c_strstr (s, "123") is also not safe. The programmer needs to have the
> > precise criteria.
>
> I don't quite follow this. c_strstr (S, "x") is safe in all cases; it
> never has undefined behavior. I
Hi,
Paul Eggert noted that vasnprintf should be able to return strings of length
> INT_MAX. Here's a patch to that effect.
Yoann, is the vsnprintf.c patch OK with you? It corresponds to Paul's fixes
to snprintf.c a week ago.
2006-08-26 Bruno Haible <[EMAIL PROTECTED]>
* vasnprintf.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 8/26/2006 12:43 AM:
> I installed this into gnulib, and will install the corresponding
> coreutils patch in a few minutes.
>
> The basic idea is that source files should include config.h
> unconditionally, so that we needn'
Paul Eggert wrote a month ago:
> I was worried about the case where an implementation provides a
> conforming stdint.h but not a conforming inttypes.h. Such an
> implementation might have 64-bit int. There are a few ILP64 hosts,
> e.g., GCC on MIPS with the -mint64 option. Currently, I suspect t
34 matches
Mail list logo
