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 gnuli
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
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" writes:
> Hi,
>
> The recently introduced
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 num_
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 initi
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 type
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
> > > 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 -L/usr/local
Eric Blake wrote:
> > +# if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
>
> Is there a wine-specific preprocessor witness that we can use to
> distinguish compilation for wine vs. native?
I don't think so. The very idea of Wine is that you can take a binary built
for mingw and e
This fixes a small bug in the m4/getlogin_r.m4 macros: The presence of a
getlogin_r() declaration in depends on whether
AC_USE_SYSTEM_EXTENSIONS was already executed. And a tiny optimization
in lib/getlogin_r.c.
2010-01-09 Bruno Haible
getlogin_r: Small fixes.
* lib/getlogin_
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 with
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 wind
> 2010-01-09 Bruno Haible
>
> 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
* lib/unistd.in.h (getlogin_r): Add comment.
*** lib/unistd.in.h.origSat Ja
> > 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
Tests for module '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
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
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 thing
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 misleadin
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 10
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
* lib/dup2.c (rpl_dup2): Restore text mode when needed, to work
around Wine bug #21291.
diff --git a/li
FYI, the recent move in diffutils of $(LIBICONV) from cmp_LDADD
to LDADD, a syntax-check rule began to fail. This extends the
rule to recognize the new situation.
It could be slightly more efficient in some cases by determining
that the only programs are in say src/, and when it finds LDADD
has t
21 matches
Mail list logo
