Re: Piping sed stalls on OpenSolaris 2010.03
Hi Vladimir, > > This is most likely the same bug that Paul has already analyzed [1] > > and/or the bug that Jim has analyzed [2]. We cannot support such a buggy > > system [3][4]. I would suggest you upgrade to a newer version [5]. > Would it be possible to detect it on configure time and issue > appropriate error? I wouldn't mind. Can you propose a patch? Maybe testing whether `uname -sv` is "SunOS snv_134" is enough? Bruno
Use of gnulib's cfg.mk
I see that gnulib has its own cfg.mk which is used, for example, to skip some syntax-check checks on gnulib's own code. It also has its own Makefile.am. In GNU Zile I get these by virtue of having gnulib as a git submodule. However, GNU Hello uses Bazaar, and I can't see a way to include a git submodule. How do I get these files using just gnulib-tool? For example, I can't see that gnulib's cfg.mk is mentioned by any module. hello stores all its gnulib files under TOPLEVEL/gnulib, but currently adds "gnulib/lib" to its top-level Makefile.am's SUBDIRS; presumably I want to change that to just "gnulib". -- http://rrt.sc3d.org
Re: Use of gnulib's cfg.mk
Reuben Thomas wrote: > I see that gnulib has its own cfg.mk which is used, for example, to > skip some syntax-check checks on gnulib's own code. > ... > I can't see that gnulib's cfg.mk is mentioned by any module. Yes, $ ./gnulib-tool --find cfg.mk shows that cfg.mk is not contained in any module. This is because it describes syntax rules for the gnulib source code, not for the Zile or Hello source code. You are supposed to use a cfg.mk file of your own in Zile or Hello. > It also has its own Makefile.am. No, gnulib does not have a Makefile.am. It has a couple of Makefiles, though. They are also not meant to be copied into your package. > I can't see a way to include a git submodule. How do I get these files > using just gnulib-tool? gnulib-tool has an option --copy-file that can retrieve a single file out of the gnulib repository, independently of any modules. It's sometimes useful for config.guess and config.sub. But please think twice before using it! Bruno
Re: Use of gnulib's cfg.mk
On 14 April 2012 19:44, Bruno Haible wrote: > Reuben Thomas wrote: >> I see that gnulib has its own cfg.mk which is used, for example, to >> skip some syntax-check checks on gnulib's own code. >> ... >> I can't see that gnulib's cfg.mk is mentioned by any module. > > Yes, > $ ./gnulib-tool --find cfg.mk > shows that cfg.mk is not contained in any module. This is because it > describes syntax rules for the gnulib source code, not for the Zile > or Hello source code. OK, I'm obviously misunderstanding how Zile escapes performing the syntax checks on files in gnulib. -- http://rrt.sc3d.org
pathmax on MSVC
On MSVC 9, a testdir for module 'stat' does not build: source='stat.c' object='stat.obj' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../build-aux/depcomp \ /home/bruno/msvc/compile cl -nologo -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=1 -D_WIN32_WINNT=_WIN32_WINNT_WINXP -I/usr/local/msvc/include -MD -c `cygpath -w 'stat.c'` stat.c c:\cygwin\home\bruno\multibuild-2062\msvc9\testdir1\gllib\pathmax.h(42) : fatal error C1083: include file cannot be opened: "unistd.h": No such file or directory make[4]: *** [stat.obj] Error 2 This fixes it: 2012-04-14 Bruno Haible pathmax: Fix compilation error on MSVC 9. * modules/pathmax (Depends-on): Add unistd. --- modules/pathmax.origSat Apr 14 21:35:26 2012 +++ modules/pathmax Sat Apr 14 21:34:37 2012 @@ -6,6 +6,7 @@ m4/pathmax.m4 Depends-on: +unistd configure.ac: gl_PATHMAX
stat() on mingw64
The 'stat' module makes two checks:
checking whether stat handles trailing slashes on directories...
checking whether stat handles trailing slashes on files...
On native Windows, the results are:
* for mingw and MSVC 9:
checking whether stat handles trailing slashes on directories... no
checking whether stat handles trailing slashes on files... yes
* for mingw64:
checking whether stat handles trailing slashes on directories... yes
checking whether stat handles trailing slashes on files... no
This behaviour comes from a definition of stat() in libmingwex.a.
These bright guys (the mingw64 developers) meant to fix one stat() bug,
but
1) in the process, opened another bug,
2) did not apply their fix to the other variants (_stat, _stat64, etc.)
Witness:
=== foo.c ===
#include
#include
#include
int main ()
{
{
struct stat st;
int ret1 = stat (".", &st);
int ret2 = stat ("./", &st);
int ret3 = stat ("conftest.tmp/", &st);
printf ("%d %d %d\n", ret1, ret2, ret3);
}
{
struct _stat st;
int ret1 = _stat (".", &st);
int ret2 = _stat ("./", &st);
int ret3 = _stat ("conftest.tmp/", &st);
printf ("%d %d %d\n", ret1, ret2, ret3);
}
{
struct _stati64 st;
int ret1 = _stati64 (".", &st);
int ret2 = _stati64 ("./", &st);
int ret3 = _stati64 ("conftest.tmp/", &st);
printf ("%d %d %d\n", ret1, ret2, ret3);
}
{
struct _stat64 st;
int ret1 = _stat64 (".", &st);
int ret2 = _stat64 ("./", &st);
int ret3 = _stat64 ("conftest.tmp/", &st);
printf ("%d %d %d\n", ret1, ret2, ret3);
}
return 0;
}
=
$ touch conftest.tmp
$ i686-w64-mingw32-gcc foo.c
$ ./a.exe
0 0 0
0 -1 -1
0 -1 -1
0 -1 -1
gnulib's override currently works OK, but can optimized: There is no
need for gnulib to work around a bug introduced by mingw64's override.
Just use the underlying function from MSVCRT.DLL.
2012-04-14 Bruno Haible
stat: Bypass buggy override in mingw64.
* m4/stat.m4 (gl_FUNC_STAT): Update comments.
* lib/stat.c (stat) [mingw64]: Define to _stat.
* doc/posix-functions/stat.texi: Mention mingw64 bug.
--- doc/posix-functions/stat.texi.orig Sat Apr 14 22:08:42 2012
+++ doc/posix-functions/stat.texi Sat Apr 14 22:07:30 2012
@@ -15,7 +15,7 @@
@item
On some platforms, @code{stat("link-to-file/",buf)} succeeds instead
of failing with @code{ENOTDIR}.
-FreeBSD 7.2, AIX 7.1, Solaris 9.
+FreeBSD 7.2, AIX 7.1, Solaris 9, mingw64.
@item
On some platforms, @code{stat(".",buf)} and @code{stat("./",buf)} give
different results:
--- lib/stat.c.orig Sat Apr 14 22:08:42 2012
+++ lib/stat.c Sat Apr 14 22:07:30 2012
@@ -27,6 +27,15 @@
#include
#undef __need_system_sys_stat_h
+#if ((defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__) \
+&& REPLACE_FUNC_STAT_FILE
+/* mingw64 has a broken stat() function, based on _stat(), in libmingwex.a.
+ Bypass it. */
+# define stat _stat
+# define REPLACE_FUNC_STAT_DIR 1
+# undef REPLACE_FUNC_STAT_FILE
+#endif
+
static inline int
orig_stat (const char *filename, struct stat *buf)
{
--- m4/stat.m4.orig Sat Apr 14 22:08:42 2012
+++ m4/stat.m4 Sat Apr 14 22:07:30 2012
@@ -1,4 +1,4 @@
-# serial 8
+# serial 9
# Copyright (C) 2009-2012 Free Software Foundation, Inc.
#
@@ -23,8 +23,9 @@
mingw*) gl_cv_func_stat_dir_slash="guessing no";;
*) gl_cv_func_stat_dir_slash="guessing yes";;
esac])])
- dnl AIX 7.1, Solaris 9 mistakenly succeed on stat("file/")
- dnl FreeBSD 7.2 mistakenly succeeds on stat("link-to-file/")
+ dnl AIX 7.1, Solaris 9, mingw64 mistakenly succeed on stat("file/").
+ dnl (For mingw, this is due to a broken stat() override in libmingwex.a.)
+ dnl FreeBSD 7.2 mistakenly succeeds on stat("link-to-file/").
AC_CACHE_CHECK([whether stat handles trailing slashes on files],
[gl_cv_func_stat_file_slash],
[touch conftest.tmp
Re: mingw and AC_SYS_LARGEFILE
Here's a proposed patch for Large File Support for native Windows platforms.
Tested on mingw, mingw64 (32-bit), MSVC 9.
It turns out there's nothing to do with open(), creat() - because there is
no need for O_LARGEFILE on Windows - and also nothing to do with fopen(),
fgetpos(), fsetpos() - because fpos_t is already 64-bit on Windows -.
Opinions? Objections? Jim, in particular it touches the 'ftruncate' module,
which is yours.
2012-04-14 Bruno Haible
Large File Support for native Windows platforms.
* m4/largefile.m4 (gl_LARGEFILE): New macro.
* modules/largefile (configure.ac): Require gl_LARGEFILE.
* lib/sys_types.in.h (off_t) [USE_64_BIT_OFF_T]: Define to a 64-bit
type.
* m4/sys_types_h.m4 (gl_SYS_TYPES_H): Set USE_64_BIT_OFF_T.
* modules/sys_types (Makefile.am): Substitute USE_64_BIT_OFF_T.
* doc/posix-headers/sys_types.texi: Mention the effect of the
'largefile'
module.
* lib/fcntl.in.h: Add comments about off_t.
* modules/fcntl-h (Depends-on): Add sys_types.
* lib/unistd.in.h [USE_64_BIT_OFF_T]: Include .
(ftruncate): Replace it if REPLACE_FTRUNCATE is 1.
* m4/unistd_h.m4 (gl_UNISTD_H): Require gl_SYS_TYPES_H.
(gl_UNISTD_H_DEFAULTS): Initialize REPLACE_FTRUNCATE.
* modules/unistd (Depends-on): Add sys_types.
(Makefile.am): Substitute USE_64_BIT_OFF_T, REPLACE_FTRUNCATE.
* lib/lseek.c (rpl_lseek) [_GL_USE_64_BIT_OFF_T]: Use _lseeki64 instead
of lseek.
* m4/lseek.m4 (gl_FUNC_LSEEK): Require gl_SYS_TYPES_H. Set REPLACE_LSEEK
if USE_64_BIT_OFF_T is 1.
* modules/lseek (Depends-on): Add sys_types.
* lib/ftruncate.c: Put under GPLv3+. Include ,
msvc-nothrow.h.
(SetFileSize): New function.
(ftruncate) [_GL_USE_64_BIT_OFF_T]: New implementation.
* m4/ftruncate.m4 (gl_FUNC_FTRUNCATE): Require gl_SYS_TYPES_H. Set
REPLACE_FTRUNCATE if USE_64_BIT_OFF_T is 1.
* modules/ftruncate (configure.ac): Consider REPLACE_FTRUNCATE.
(Depends-on): Add sys_types, msvc-nothrow. Update conditions.
* lib/sys_stat.in.h: Add comments about off_t.
(stat, fstat) [USE_64_BIT_OFF_T]: Define to variants that use a 64-bit
integer for st_size in 'struct stat'.
* modules/sys_stat (Depends-on): Add sys_types.
(Makefile.am): Substitute USE_64_BIT_OFF_T.
* lib/stat.c (stat) [_GL_USE_64_BIT_OFF_T]: Define to _stati64 instead
of stat or _stat.
* lib/fstat.c [_GL_USE_64_BIT_OFF_T]: Use _fstati64 and 'struct
_stati64'
instead of fstat and 'struct stat'.
* m4/fstat.m4 (gl_FUNC_FSTAT): Require gl_SYS_TYPES_H. Set REPLACE_FSTAT
if USE_64_BIT_OFF_T is 1.
* modules/fstat (Depends-on): Add sys_types.
* lib/stdio.in.h: Add comments about off_t.
* modules/stdio (Depends-on): Add sys_types.
* lib/ftello.c [_GL_USE_64_BIT_OFF_T]: Use _ftelli64 or ftello64 instead
of ftello.
* m4/ftello.m4 (gl_FUNC_FTELLO): Require gl_SYS_TYPES_H. Set
REPLACE_FTELLO if USE_64_BIT_OFF_T is 1.
(gl_PREREQ_FTELLO): New macro.
* modules/ftello (Depends-on): Add sys_types.
(configure.ac): Incoke gl_PREREQ_FTELLO.
* lib/fseeko.c [_GL_USE_64_BIT_OFF_T]: Use _fseeki64 or fseeko64 instead
of fseeko.
* m4/fseeko.m4 (gl_FUNC_FSEEKO): Require gl_SYS_TYPES_H. Set
REPLACE_FSEEKO if USE_64_BIT_OFF_T is 1.
(gl_PREREQ_FSEEKO): New macro.
* modules/fseeko (Depends-on): Add sys_types.
(configure.ac): Invoke gl_PREREQ_FSEEKO.
Reported by Ray Satiro .
--- doc/posix-headers/sys_types.texi.orig Sat Apr 14 22:55:20 2012
+++ doc/posix-headers/sys_types.texiSat Apr 14 22:28:42 2012
@@ -27,5 +27,8 @@
On some platforms the types @code{blksize_t} and @code{suseconds_t}
are signed integer types that are wider than @code{long}:
glibc x32
-
@end itemize
+
+This module, together with the module @code{largefile}, also defines the type
+@code{off_t} to a 64-bit integer type on some platforms:
+mingw, MSVC 9.
--- lib/fcntl.in.h.orig Sat Apr 14 22:55:20 2012
+++ lib/fcntl.in.h Sat Apr 14 22:28:42 2012
@@ -25,6 +25,8 @@
#if defined __need_system_fcntl_h
/* Special invocation convention. */
+/* Needed before .
+ May also define off_t to a 64-bit type on native Windows. */
#include
/* On some systems other than glibc, is a prerequisite of
. On glibc systems, we would like to avoid namespace pollution.
@@ -42,6 +44,8 @@
#ifndef _@GUARD_PREFIX@_FCNTL_H
+/* Needed before .
+ May also define off_t to a 64-bit type on native Windows. */
#include
/* On some systems other than glibc, is a prerequisite of
. On glibc systems, we would like to avoid namespace pollution.
--- lib/fseeko.c.orig Sat Apr 14 22:55:20 2012
+++ lib/fseeko.cSat Apr 14 22:28:42 2012
@@ -31,6 +31,14 @@
# undef fseek
Re: mingw and AC_SYS_LARGEFILE
Bruno Haible wrote: > Here's a proposed patch for Large File Support for native Windows platforms. > Tested on mingw, mingw64 (32-bit), MSVC 9. > > It turns out there's nothing to do with open(), creat() - because there is > no need for O_LARGEFILE on Windows - and also nothing to do with fopen(), > fgetpos(), fsetpos() - because fpos_t is already 64-bit on Windows -. > > Opinions? Objections? Jim, in particular it touches the 'ftruncate' module, > which is yours. Hi Bruno, Thanks for all the work. The new code looks fine, and I'm sure you've tested it thoroughly, but the new names, gl_LARGEFILE and USE_64_BIT_OFF_T sound like things that one would use and expect to be set (resp.) even on non-Windows systems. What do you think about changing the names to make it clear that they are useful only when building on mingw? > --- m4/largefile.m4.orig Sat Apr 14 22:55:20 2012 ... > +# Enable large files on systems where this is implemented by Gnulib, not by > the > +# system headers. > +AC_DEFUN([gl_LARGEFILE], > +[ > + AC_REQUIRE([AC_CANONICAL_HOST]) > + case "$host_os" in > +mingw*) # native Windows > + USE_64_BIT_OFF_T=1 ;; > +*) > + USE_64_BIT_OFF_T=0 ;; > + esac > +])
