On 3-Jul-2011, Bruno Haible wrote:
| subdirectory modules/fortran/ -, and that you follow the GNU conventions for
| Fortran code (whatever these may be - you can find out by looking at octave
| in octave-3.4.2/libcruft/ [3]).
I wouldn't recommend trying to follow the style of the Fortran code
On 07/20/2011 06:00 PM, Bruno Haible wrote:
Hi Sam,
Why does close depend on fclose?!
The justification was in
http://lists.gnu.org/archive/html/bug-gnulib/2008-10/msg00201.html.
It seems that, close being a system call and fclose being a C library
function, the dependency should be the
* Bruno Haible oe...@pyvfc.bet [2011-07-21 02:19:07 +0200]:
I pulled ioctl module from gnulib because of a compilation error about
ioctl_used_without_requesting_gnulib_ioctl and I am wondering whether
the HAVE_RELIABLE_FIONREAD et al are still relevant.
The problem that
On 07/21/11 03:57, Bruno Haible wrote:
Is that the kind of rule you would recommend?
Yes, something like that might work, for config.status in Emacs.
But I'd rather not debug this sort of thing myself.
Like you, I'm leery of time stamp files; too often
their costs outweigh their benefits.
Paul Eggert wrote:
Like you, I'm leery of time stamp files; too often
their costs outweigh their benefits.
What are, concretely, the problems you are fearing, or that you remember
from the past? In other words, which are the tests that we should perform
before committing a change that makes use
[Adding bug-gnulib; the original bug report is http://debbugs.gnu.org/9141.]
On 07/21/11 02:16, Herb Wartens wrote:
I have added a hack to get coreutils to compile cleanly on OSX.
Thanks, but we should fix this problem more cleanly. Does the
following patch to lib/stdint.in.h solve your
On 07/21/11 14:27, Bruno Haible wrote:
What are, concretely, the problems you are fearing, or that you remember
from the past? In other words, which are the tests that we should perform
before committing a change that makes use of stamp files?
Your earlier message summarized the problems that
On 07/21/11 02:16, Herb Wartens wrote:
OSX does have fdatasync defined as part of the libsystem_kernel.dylib library.
The problem is that there is no header on OSX that actually provides the
function.
Thanks again for reporting this.
What is the exact symptom of failure here?
If 'configure'
Sam Steingold wrote:
The problem that clisp/src/m4/ioctl.m4 tests against is fixed in Solaris 7
and newer, but is present in Solaris 2.6, FreeBSD 6.4, IRIX 6.5.
are they still porting targets?
could you please move this to gnulib from clisp?
FreeBSD 6.4 is not so different from the newest
* Bruno Haible oe...@pyvfc.bet [2011-07-22 00:18:04 +0200]:
-extern DIR *fdopendir (int);
+extern
+# ifdef __cplusplus
+C
+# endif
+DIR *fdopendir (int);
that's pretty awful.
maybe there is a way to use the m4 magic to avoid replacing 1 line with 5?
--
Sam Steingold
Bruno Haible wrote:
Paul, Jim, Eric, others, do you remember other problems of stamp files?
The config.h rule (among others) has been using one for years,
and the last time I've heard complaints or bug reports about it
has been years also.
For reference, here's the rules automake generates
On 07/21/11 02:16, Herb Wartens wrote:
I have added a hack to get coreutils to compile cleanly on OSX.
Thanks, but we should fix this problem more cleanly. Does the
following patch to lib/stdint.in.h solve your problem? This fix is
already scheduled to appear in the next version of
On Thu, Jul 21, 2011 at 3:08 PM, Paul Eggert egg...@cs.ucla.edu wrote:
On 07/21/11 02:16, Herb Wartens wrote:
OSX does have fdatasync defined as part of the libsystem_kernel.dylib
library.
The problem is that there is no header on OSX that actually provides the
function.
Thanks again for
13 matches
Mail list logo
