There is another dup2 failure due to Wine, see:
http://bugs.winehq.org/show_bug.cgi?id=21291
The patch below works around it. Thoughts?
/Simon
2010-01-09 Simon Josefsson si...@josefsson.org
* lib/dup2.c (rpl_dup2): Restore text mode when needed, to work
around Wine bug
This problem was also caused by Wine, and not visible under Windows XP.
See http://bugs.winehq.org/show_bug.cgi?id=21292
My old patch fixes the problem under Wine, but this updated patch adds a
comment explaining.
Ok to push?
/Simon
diff --git a/m4/open.m4 b/m4/open.m4
index d705b3a..bc04613
Hi Simon,
Simon Josefsson wrote:
I got this when cross-compiling to MinGW with Wine:
test-open.h:34: assertion failed
FAIL: test-open.exe
Whereas on a real Windows XP SP3, I get:
skipping test: symlinks not supported on this file system
SKIP: test-open.exe
(which is a bit misleading:
Hi John,
John W. Eaton wrote:
Looking at lib/glob.c in the gnulib sources, there is some
Windows-specific code, so it looks like it is intended to work on
Windows systems
Is glob.c expected to work on Windows systems?
At least it passes its unit test on mingw.
but there are some things
John W. Eaton wrote:
I'm using the glob module in GNU Octave and a Windows user complained
that linking failed with an undefined reference to getlogin.
You mean getlogin or getlogin_r?
The problem appears to be that getlogin_r is called from glob, and the
gnulib replacement for getlogin_r
Simon Josefsson wrote:
diff --git a/m4/open.m4 b/m4/open.m4
index d705b3a..bc04613 100644
--- a/m4/open.m4
+++ b/m4/open.m4
@@ -8,7 +8,7 @@ AC_DEFUN([gl_FUNC_OPEN],
[
AC_REQUIRE([AC_CANONICAL_HOST])
case $host_os in
-mingw* | pw*)
+pw*)
gl_REPLACE_OPEN
;;
the gnulib replacement for getlogin_r calls getlogin unconditionally, but
getlogin doesn't exist on Windows systems.
Oh, I see now what you mean. The cause is that getlogin_r had no unit test.
I'm adding this test:
2010-01-09 Bruno Haible br...@clisp.org
Tests for module
2010-01-09 Bruno Haible br...@clisp.org
Tests for module 'getlogin_r'.
* modules/getlogin_r-tests: New file.
* tests/test-getlogin_r.c: New file.
And a comment:
2010-01-09 Bruno Haible br...@clisp.org
* lib/unistd.in.h (getlogin_r): Add comment.
***
According to Simon Josefsson on 1/9/2010 4:06 AM:
There is another dup2 failure due to Wine, see:
http://bugs.winehq.org/show_bug.cgi?id=21291
The patch below works around it. Thoughts?
Hmm. Repeatedly adding workarounds for wine bugs seems awkward. If the
goal is making wine a windows
On 01/09/2010 12:33 PM, Bruno Haible wrote:
Hmm, you and Paolo explained to me on 2009-08-21 that Wine should be
considered as a platform of its own. But I still don't fully agree. Can
you first report the bug to the Wine people and come back to patching
gnulib only if they are not fixing it
This fixes a small bug in the m4/getlogin_r.m4 macros: The presence of a
getlogin_r() declaration in unistd.h depends on whether
AC_USE_SYSTEM_EXTENSIONS was already executed. And a tiny optimization
in lib/getlogin_r.c.
2010-01-09 Bruno Haible br...@clisp.org
getlogin_r: Small fixes.
the gnulib replacement for getlogin_r calls getlogin unconditionally, but
getlogin doesn't exist on Windows systems.
Oh, I see now what you mean. The cause is that getlogin_r had no unit test.
The new unit test indeed fails to link on mingw:
gcc -mno-cygwin -g -O2
John W. Eaton wrote:
getlogin doesn't exist on Windows systems.
What would be the preferred way of fixing this problem? Should there
be a separate getlogin module?
Even though getlogin_r does not require a 'getlogin' module, it is indeed
fairly easy to add:
2010-01-09 Bruno Haible
Eric Blake wrote:
Here's spin two of the patch.
[PATCH 1/4] warn-on-use: new module
...
+ supported by the compiler. If the compiler does not support this
+ feature, the macro expands to an unused typedef declaration.
It's now an 'extern' declaration, so I would change
unused typedef
Brian Gough wrote:
The fencepost automated build script encountered a problem installing
your package coreutils-8.3 on fencepost.gnu.org. The error is shown
below.
The complete log file is available at
/gd/gnu/gnusys/logs/coreutils-8.3.FAILED.log
The build environment was initialized
Hi,
The recently introduced nproc utility outputs wrong result when run in
--all mode inside a /proc-less /sys-less GNU/Linux chroot on a system
with several CPUs. In this environment, nproc --all always outputs 1
while plain nproc outputs correct number of available CPUs.
The underlying
when --all fails for any reason, I think we should try with the number
of available processing units, at least it is a more accurate value than
return 1 (and document this behaviour).
Bruno, Jim, what do you think?
Cheers,
Giuseppe
Dmitry V. Levin l...@altlinux.org writes:
Hi,
The
On 10/01/10 01:14, Giuseppe Scrivano wrote:
when --all fails for any reason, I think we should try with the number
of available processing units, at least it is a more accurate value than
return 1 (and document this behaviour).
Bruno, Jim, what do you think?
Just to summarize what's happening
Hello
I have downloaded the new gnulib source codes with the modification by
Bruno Haible. I can get successful results in linking one of the dll files
for the octave that was failed due to the getlogin problem.
Thank you very much!!
Regards
Tatsuro
--- Bruno Haible wrote:
the gnulib
19 matches
Mail list logo
