list of tests that fail,
>>> you should be able to investigate the precise problems with 'long double'.
>>
>> sorry to revive this old thread. just got some minutes to give the tests a
>> go :)
>>
> [snip]
>
> just a heads up:
>
> it see
#x27;long double'.
>
> sorry to revive this old thread. just got some minutes to give the tests a go
> :)
>
[snip]
just a heads up:
it seems that the libc on interix is built with a compiler that has 64 bit long
doubles (so it can be none of the bundled compilers, as they all have
rexpl roundl signbit sinl sqrtl tanl truncl \
> vasnprintf
> and test that package on your platform. From the list of tests that fail,
> you should be able to investigate the precise problems with 'long double'.
sorry to revive this old thread. just got some minutes to give t
Bruno Haible wrote:
>> 2) To undo the patch that introduces check_f_blocks_size, because
>> - on MacOS X 10.7 it is not needed any more after 1),
>> - on AIX and Cywin it causes non-POSIX API to be used for no reason,
>> - it kills portability to Interix 3.
> 2) To undo the patch that introduces check_f_blocks_size, because
> - on MacOS X 10.7 it is not needed any more after 1),
> - on AIX and Cywin it causes non-POSIX API to be used for no reason,
> - it kills portability to Interix 3.5.
Slight correction: It is still ne
On 06/10/11 11:37, Bruno Haible wrote:
> Hi,
>
> Markus Duft wrote:
>> long long double is broken.
>
> You surely mean "long double"? There is no such type as "long long double"
> in C.
right; long long double is too long :)
>
>> this bites me in the gnulib vasnprintf implementation, which cal
Hi,
Markus Duft wrote:
> long long double is broken.
You surely mean "long double"? There is no such type as "long long double"
in C.
> this bites me in the gnulib vasnprintf implementation, which calls snprintf
> from libc which immediately crashes ... :(
gnulib and coreutils code now assume
Hi!
While porting glib to interix, i stumbled over a problem i didn't hit for a
while (and in fact forgot that it existed on interix): long long double is
broken. this bites me in the gnulib vasnprintf implementation, which calls
snprintf from libc which immediately crashes ... :(
i
On Thursday 26 May 2011 10:43:41 Markus Duft wrote:
> On 05/25/11 22:43, Bruno Haible wrote:
> > [CCing bug-gnulib]
> >
> > Markus Duft wrote in
> > <http://lists.gnu.org/archive/html/bug-patch/2011-05/msg00023.html>:
> >> For quite a while now, i have
t; Thanks. The configure runs produce results similar to Interix 3.5., which is
> already covered in gnulib's documentation.
>
> The "make" log that you sent compiled only one file and did not fail. I
> guess that was a second "make" run after the first &q
Markus Duft wrote:
> > and send us the log files of these three commands, plus config.log and
> > gltests/config.log.
>
> all attached, except make check, as i could not run it, as make already
> failed :/
Thanks. The configure runs produce results similar to Interix 3
ror 1
>
> where /usr/include/string.h does:
>
> extern char * __cdecl mbsrchr(const char *, char);
I'm adding this workaround:
2011-05-26 Bruno Haible
mbsrchr: Avoid collision with system function on Interix.
* lib/string.in.h (mbsrchr): Define as rpl_m
On 05/26/11 10:51, Andreas Gruenbacher wrote:
> On Thursday 26 May 2011 10:43:41 Markus Duft wrote:
[snip]
>>
>> Trying to find out ;) First of all, patch seems to miss strnlen.c in the
> tarball (2.6.1).
it seems a well known problem, as even gentoo linux has a patch for this; see
[1] and [2].
[CCing bug-gnulib]
Markus Duft wrote in
<http://lists.gnu.org/archive/html/bug-patch/2011-05/msg00023.html>:
> For quite a while now, i have patch working on x86-interix with a small patch
> ( :D ). I'd really love to see this patch ([1]) go upstream, if that's ok
> w
On 05/17/11 00:40, Bruno Haible wrote:
> Hi Markus,
>
>> This is a small patch in reply to [1] to update the DEPENDENCIES for interix
>> accordingly.
>>
>> [1] http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00310.html
>> "gnulib should documen
Hi Markus,
> This is a small patch in reply to [1] to update the DEPENDENCIES for interix
> accordingly.
>
> [1] http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00310.html
> "gnulib should document that libsuacomp is a
>prerequisite for running on Interix.&
On 05/16/11 16:01, Eric Blake wrote:
> On 05/16/2011 01:47 AM, md...@s01en22.salomon.at wrote:
>> From: Markus Duft
>>
>> Hey!
>>
>> This is a small patch in reply to [1] to update the DEPENDENCIES for interix
>> accordingly.
>> suacomp 0.6.8 (whic
On 05/16/2011 01:47 AM, md...@s01en22.salomon.at wrote:
> From: Markus Duft
>
> Hey!
>
> This is a small patch in reply to [1] to update the DEPENDENCIES for interix
> accordingly.
> suacomp 0.6.8 (which is the dependency) is not yet released, but will be
> today o
From: Markus Duft
Hey!
This is a small patch in reply to [1] to update the DEPENDENCIES for interix
accordingly.
suacomp 0.6.8 (which is the dependency) is not yet released, but will be today
or tomorrow,
so i think thath is not a problem :)
[1] http://lists.gnu.org/archive/html/bug-gnulib
e sane system.
>>
>> Yes, thanks, that sounds like a better plan.
Agreed - that is, gnulib should document that libsuacomp is a
prerequisite for running on Interix.
>
> ok, i have sync() and futimes() almost finished on interix, and the good news
> is: tar is working again :)
&g
required
>> anyway to get a more sane system.
>
> Yes, thanks, that sounds like a better plan.
ok, i have sync() and futimes() almost finished on interix, and the good news
is: tar is working again :)
so thanks for the help, and keep up the good work!
regards, markus!
On 05/12/11 23:15, Markus Duft wrote:
> maybe i could even implement a futimes by memorizing the timestamps and
> re-setting them after closing the file...
>
> would that be better than hacking around in gnulib? libsuacomp is required
> anyway to get a more sane system.
Yes, thanks, that sounds
On 05/12/11 18:10, Paul Eggert wrote:
> On 05/12/11 01:38, Markus Duft wrote:
>> this doesn't help, and doesn't even compile, as interix also doesn't have
>> sync()
>
> OK, how about this patch to utimens.c instead?
tested, but doesn't help eithe
On 05/12/11 01:38, Markus Duft wrote:
> this doesn't help, and doesn't even compile, as interix also doesn't have
> sync()
OK, how about this patch to utimens.c instead?
diff --git a/lib/utimens.c b/lib/utimens.c
index c190411..f738c68 100644
--- a/lib/utimens.c
+++ b/l
7;s a simpler fix. fdutimensat calls
> futimens (fd, ts), which invokes fdutimens (fd, NULL, ts), which invokes
> fsync (fd) if HAVE_BUGGY_NFS_TIME_STAMPS is nonzero. So, please
> try prepending the following to utimens.c:
this doesn't help, and doesn't even compile, as interix a
On 05/12/11 05:41, Paul Eggert wrote:
> On 05/11/11 01:49, Markus Duft wrote:
>> fsync(fd) before setting the timestamp helps, and i have a 1.26 patch
>> (attached),
>> for now limited to interix only, although i saw it on linux too.
>
> Can you describe the GNU/Linux
vokes fdutimens (fd, NULL, ts), which invokes
fsync (fd) if HAVE_BUGGY_NFS_TIME_STAMPS is nonzero. So, please
try prepending the following to utimens.c:
#if __INTERIX
# define HAVE_BUGGY_NFS_TIME_STAMPS 1
#endif
Also, which version of Interix are you using? Is a new version available,
or are pa
>>>>
>>>>> I just created the attached patch for findutils to build. Any chance to
>>>>> get this in your git repo? :) The code is as good as it can get with
>>>>> interix, i think - improvement suggestions welcome!
>>>>
>>>>
thanks for the formatting, and sorry for the mis-formatted code.
>
>>
>> On the semantics of the patch, I don't like using NAME_MAX,
>> char node[9 + NAME_MAX];
>> (some systems don't define it at all)
>> but since this code is compiled only on Interix
>
> On the semantics of the patch, I don't like using NAME_MAX,
> char node[9 + NAME_MAX];
> (some systems don't define it at all)
> but since this code is compiled only on Interix, I didn't bother
> to change it.
>
> This commit has your name of course, but
gt; I just created the attached patch for findutils to build. Any chance to
>>>>> get this in your git repo? :) The code is as good as it can get with
>>>>> interix, i think - improvement suggestions welcome!
>>>>
>>>> To make things very clear here t
to build. Any chance to
>>>> get this in your git repo? :) The code is as good as it can get with
>>>> interix, i think - improvement suggestions welcome!
>>>
>>> To make things very clear here to gnulib folks, this is a patch
>>> against gnulib at 1778e
So, finally, i think assignments are in place :) i didn't receive a
copy of em yet (clerk told me he'll send the copy now a few weeks
Donald sent you the PDF's on Mon Dec 06 18:39:39 2010 (don't know time
zone, maybe US/Eastern). It was an attachment apparently named
"Duft.627645..tar.gz"
On 10/21/2010 02:30 PM, Jim Meyering wrote:
> Markus Duft wrote:
>>> I see that you have FSF copyright assignments on file
>>> for other projects, but not yet for gnulib.
>>> Can you start that process?
>>> Once that's done, we can proceed.
>>
>> phew - the other assignments are quite a while ago -
On 10/29/2010 07:49 AM, Markus Duft wrote:
On 10/29/2010 01:11 AM, Paolo Bonzini wrote:
On 10/28/2010 04:59 PM, Markus Duft wrote:
thinking of gnulib, i can see a lot of potential problems,
starting fex, that gnulib modules are copied into the packages,
rather than gnulib beeing an installed li
On 10/29/2010 01:11 AM, Paolo Bonzini wrote:
> On 10/28/2010 04:59 PM, Markus Duft wrote:
>> thinking of gnulib, i can see a lot of potential problems, starting fex,
>> that gnulib
>> modules are copied into the packages, rather than gnulib beeing an installed
>> library
>> that is linked against
On 10/28/2010 04:59 PM, Markus Duft wrote:
thinking of gnulib, i can see a lot of potential problems, starting fex, that
gnulib
modules are copied into the packages, rather than gnulib beeing an installed
library
that is linked against (is this true always?).
It is true that gnulib is usually
On 10/28/2010 04:16 PM, Eric Blake wrote:
[snip]
>
> That's exactly what gnulib is - a library of source code workarounds for
> broken platform functions. Are you interested in porting your
> libsuacomp fixes into gnulib, so that more GNU programs can support
> Interix ou
that Eric suggested. And perhaps treating
>>> ENOMEM like E2BIG when execve fails, for Interix.
>>
>> mhm - that'd be ok with me.
>>
>> another solution that came to my mind: i'm maintaining a library, who's sole
>> purpose is to fix the incorrect beh
Hi!
I just created the attached patch for findutils to build. Any chance to
get this in your git repo? :) The code is as good as it can get with
interix, i think - improvement suggestions welcome!
Thanks!
Markus
diff -ru findutils-4.5.9.orig/gnulib/lib/mountlist.c findutils-4.5.9/gnulib/lib
Markus Duft wrote:
>> I see that you have FSF copyright assignments on file
>> for other projects, but not yet for gnulib.
>> Can you start that process?
>> Once that's done, we can proceed.
>
> phew - the other assignments are quite a while ago - i can't remember
> the exact process. can you help
> I see that you have FSF copyright assignments on file
> for other projects, but not yet for gnulib.
> Can you start that process?
> Once that's done, we can proceed.
phew - the other assignments are quite a while ago - i can't remember
the exact process. can you help me a little? where can i get
Markus Duft wrote:
> On 10/21/2010 11:59 AM, James Youngman wrote:
>> On Thu, Oct 21, 2010 at 10:05 AM, Markus Duft wrote:
>>> Hi!
>>>
>>> I just created the attached patch for findutils to build. Any chance to
>>> get this in your git repo? :) The c
On 10/21/2010 11:59 AM, James Youngman wrote:
> On Thu, Oct 21, 2010 at 10:05 AM, Markus Duft wrote:
>> Hi!
>>
>> I just created the attached patch for findutils to build. Any chance to
>> get this in your git repo? :) The code is as good as it can get with
>&g
On Thu, Oct 21, 2010 at 10:05 AM, Markus Duft wrote:
> Hi!
>
> I just created the attached patch for findutils to build. Any chance to
> get this in your git repo? :) The code is as good as it can get with
> interix, i think - improvement suggestions welcome!
To make things ver
Hi!
I just created the attached patch for findutils to build. Any chance to
get this in your git repo? :) The code is as good as it can get with
interix, i think - improvement suggestions welcome!
Thanks!
Markus
diff -ru findutils-4.5.9.orig/gnulib/lib/mountlist.c findutils-4.5.9/gnulib/lib
Simon Josefsson wrote:
> Markus Duft writes:
>
>> Hey!
>>
>> a while ago you guys implemented a select() fix for interix 3.5 (thanks
>> again ;)). now i was surprised to see the same issue come up again (it's
>> there since a while now again, just had
Markus Duft writes:
> Hey!
>
> a while ago you guys implemented a select() fix for interix 3.5 (thanks
> again ;)). now i was surprised to see the same issue come up again (it's
> there since a while now again, just had no time to dig into the problem).
>
> i now had
Hey!
a while ago you guys implemented a select() fix for interix 3.5 (thanks
again ;)). now i was surprised to see the same issue come up again (it's
there since a while now again, just had no time to dig into the problem).
i now had some time to look into it, and i discovered, that sele
> Date: Wed, 17 Jun 2009 19:58:58 -0600
> From: e...@byu.net
>
> With that in place, Jay, would you mind testing this latest snapshot?
>
> http://home.comcast.net/~ericblake/m4-1.4.13.3-5f008.tar.gz [1.3M]
> .gz.asc
> .tar.bz2 [992K]
> .bz2.asc
> .xz [822K]
> .xz.asc
> http://home.comcast.net/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 6/17/2009 2:37 AM:
> Eric Blake wrote:
>> gnulib can work around missing ESTALE, but we
>> would need to port errno_h.m4 to detect interix's situation
>
> Done as follows:
With that in place, Jay, would you mind testing t
Eric Blake wrote:
> gnulib can work around missing ESTALE, but we
> would need to port errno_h.m4 to detect interix's situation
Done as follows:
2009-06-17 Bruno Haible
Define missing ESTALE on Interix 3.5.
* lib/errno.in.h (ESTALE): Assign a value if missing.
aperwork,
And that's the very reason why gnulib support for Interix is so lacking -
no one seems to be serious enough about the platform to offer maintenance
support. Even being willing to run regression tests and post autobuild
results on a regular basis, which does not require copyrigh
y headers.
Thanks for the report. Yes, gnulib can work around missing ESTALE,
but we
would need to port errno_h.m4 to detect interix's situation on which
errno's are already defined. Interix has not had a champion on the
gnulib
list lately, so if you are willing, please step in
ESTALE, but we
would need to port errno_h.m4 to detect interix's situation on which
errno's are already defined. Interix has not had a champion on the gnulib
list lately, so if you are willing, please step in to help us port to your
platform. Are there any other errors besides ESTAL
Bruno Haible writes:
> Here is a series of two proposed patches to provide a workaround.
> Simon, is that OK to commit?
I am back from vacation now. Yes, that looks fine, but I haven't tested
it. Thanks for working on it. It will get tested by me eventually,
after the next --import run.
/Sim
Jim Meyering wrote:
> > select (0, rfds, wfds, xfds, timeout) is supposed to be equivalent to
> > select (0, NULL, NULL, NULL, timeout) and supposed to be equivalent to
> > select (n, NULL, NULL, NULL, timeout) for any n > 0. ...
>
> I agree.
OK, I committed the patch.
Bruno
>
> Jim Meyering wrote:
> > > + /* Interix 3.5 has a bug: it does not support nfds == 0. */
> > > + if (nfds == 0)
> > > +{
> > > + nfds = 1;
> > > + rfds = NULL;
> > > + wfds = NULL;
> > > + xfds =
Bruno Haible wrote:
> Jim Meyering wrote:
>> > + /* Interix 3.5 has a bug: it does not support nfds == 0. */
>> > + if (nfds == 0)
>> > +{
>> > + nfds = 1;
>> > + rfds = NULL;
>> > + wfds = NULL;
>> > + xf
Jim Meyering wrote:
> > + /* Interix 3.5 has a bug: it does not support nfds == 0. */
> > + if (nfds == 0)
> > +{
> > + nfds = 1;
> > + rfds = NULL;
> > + wfds = NULL;
> > + xfds = NULL;
> > +}
>
> Did you consi
lect (Files): Add lib/select.c, remove
> lib/winsock-select.c.
> (configure.ac): Update.
Thanks for doing the work!
Only one question:
> --- lib/select.c.orig 2009-03-12 11:36:40.0 +0100
...
> +int
> +rpl_select (int nfds, fd_set *rfds, fd_set *wfds, fd_set *xfd
then
- AC_LIBOBJ([winsock-select])
+ AC_LIBOBJ([select])
fi
gl_SYS_SELECT_MODULE_INDICATOR([select])
2009-03-12 Bruno Haible
Work around select() bug on Interix 3.5.
* lib/sys_select.in.h (select): Also replace if REPLACE_SELECT is 1.
* lib/select.c (rpl_sel
Mon Sep 17 00:00:00 2001
> From: Markus Duft
> Date: Wed, 11 Mar 2009 13:47:22 +0100
> Subject: [PATCH] * lib/nanosleep.c (my_usleep): Use 1, not 0, as the
> first argument.
>
> This avoids a failure on Interix 3.5. Details in
> http://thread.gmane.org/gmane.comp.gnu.c
Simon Josefsson wrote:
> Jim Meyering writes:
>
>> +* lib/nanosleep.c (my_usleep): Use 1, not 0, as the first argument.
>> +This avoids a failure on Interix 3.5. Details in
>> +http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/16077
>
> Is this the
> > That looks fine as the first param to select
> > is the highest-numbered file descriptor + 1.
> > Arguably 1 is more correct than 0.
I think this patch is fine. OTOH 1 is *not* more correct than 0, because it
implies that fd 0 might be tested.
The other uses are for WinSock only, so they sh
Jim Meyering writes:
> + * lib/nanosleep.c (my_usleep): Use 1, not 0, as the first argument.
> + This avoids a failure on Interix 3.5. Details in
> + http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/16077
Is this the best solution? It seems that another solution wo
Pádraig Brady wrote:
> Markus Duft wrote:
>> Hi!
>>
>> I have a more or less trivial patch for the nanosleep replacement for
>> interix. The problem I ran into is, that select() has a bug, making it fail
>> with "bad address" if the number of fd's to
Markus Duft wrote:
> Hi!
>
> I have a more or less trivial patch for the nanosleep replacement for
> interix. The problem I ran into is, that select() has a bug, making it fail
> with "bad address" if the number of fd's to select on is zero. Setting the
> set-
On Fri, Oct 24, 2008 at 02:23:03AM +0200, Bruno Haible wrote:
> But in this case, there is a cheap workaround that I can apply even without
> testing.
That indeed fixes the problem, reports Aleksey.
Thanks!
Thomas
Eric Blake wrote:
> Thanks for the report. This means that the gnulib sigaction module (a
> dependency of fatal-signal) has not yet been ported to Interix. I don't
> have access to Interix, so I'm not in a position to write the patch. Care
> to offer a hand? In general,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding bug-gnulib]
According to Thomas Klausner on 10/23/2008 3:18 PM:
> Aleksey Cheusov <[EMAIL PROTECTED]> has reported a problem with building
> m4-1.4.12 on Interix. Here's his mail:
>
> - Forwarded message from
[Dropping the Austin Group from the CCs, since Interix does not attempt
POSIX compliance.]
Jason Zions wrote:
> A few hundred thousand users of applications ported to that environment
> might disagree. Interix and the Vista/WS08 Subsystem for UNIX Applications
> do not include an sa_
Eric Blake wrote:
> > m4_if(m4_version_compare(m4_defn([m4_PACKAGE_VERSION]),[2.62]),[-1],
> > [AC_REQUIRE([AC_GNU_SOURCE])],
> > [AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])])
>
> Why not the simpler:
>
> m4_ifndef([AC_USE_SYSTEM_EXTENSIONS],
> [AC_DEFUN([AC_USE_SYSTEM_EXTENSIONS]
e system does not provide POSIX.1 features
+ except with this defined.])
+AC_DEFINE([_MINIX], [1],
+ [Define to 1 if on MINIX.])
+ fi
AH_VERBATIM([__EXTENSIONS__],
-[/* Enable extensions on Solaris. */
-#ifndef __EXTENSIONS__
-# undef __EXTENSIONS__
+[/* Enable extensions on AI
le.com/Re%3A-autoconf-enhancement-for-Interix-tf4374487.html#a12637270
Sent from the Gnulib mailing list archive at Nabble.com.
Eric Blake wrote:
> Here's the corresponding gnulib patch. OK to apply?
I would feel a little safer if you would turn the AC_REQUIRE([AC_GNU_SOURCE])
into AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS]) rather than omitting them. If
some piece of autoconf macro needs to be used at "early" time, this
order
Noah Misch cs.caltech.edu> writes:
> > 2007-09-08 Eric Blake byu.net>
> >
> > Centralize all system extensions checks.
> > * lib/autoconf/specific.m4 (AC_USE_SYSTEM_EXTENSIONS): Inline code
> > from AC_AIX, AC_GNU_SOURCE, AC_MINIX.
On Sat, Sep 08, 2007 at 10:13:03PM -0600, Eric Blake wrote:
> 2007-09-08 Eric Blake <[EMAIL PROTECTED]>
>
> Centralize all system extensions checks.
> * lib/autoconf/specific.m4 (AC_USE_SYSTEM_EXTENSIONS): Inline code
> from AC_AIX, AC_GNU_SOURCE, A
ralize all system extensions checks.
* lib/autoconf/specific.m4 (AC_USE_SYSTEM_EXTENSIONS): Inline code
from AC_AIX, AC_GNU_SOURCE, AC_MINIX. Add Interix support.
(AC_AIX, AC_GNU_SOURCE, AC_MINIX): Obsolete, and point to
AC_USE_SYSTEM_EXTENSIONS.
(AC_ISC_POSIX):
On Mon, 3 Sep 2007, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Adding gnulib: this thread started at
http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/5717]
thanks for the link and for pointing out the existence of
AC_USE_SYSTEM_EXTENSIONS. I think this is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Adding gnulib: this thread started at
http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/5717]
According to Eric Blake on 9/3/2007 4:50 PM:
> Martin Koeppe gmx.de> writes:
>
> Hello Martin,
>
>> thanks for the link and for pointing out the
"James Youngman" <[EMAIL PROTECTED]> writes:
> I propose also the following documentation patch.
OK, thanks, except that's a tad wordy. I installed this shorter
one instead:
2007-05-03 Paul Eggert <[EMAIL PROTECTED]>
* m4/d-ino.m4 (gl_CHECK_TYPE_STRUCT_DIRENT_D_INO): Use better
I propose also the following documentation patch.
2007-05-03 James Youngman <[EMAIL PROTECTED]>
* m4/d-ino.m4: Indicate that D_INO_IN_DIRENT is defined only
if the d_ino member of struct dirent contains a value that is
ever useful.
diff -u -p -r1.11 d-ino.m4
--- m4/d-ino.
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Kaz Sasayama <[EMAIL PROTECTED]> writes:
>
>>1. Modify the configure test for d_ino member in struct dirent to
>> fail on Interix and process as if there is no d_ino member.
>
> Sounds good. I installed the fol
Kaz Sasayama <[EMAIL PROTECTED]> writes:
>1. Modify the configure test for d_ino member in struct dirent to
> fail on Interix and process as if there is no d_ino member.
Sounds good. I installed the following into gnulib; does it fix your
problem?
*
gnulib's getcwd fails to get the working directory and almost always
returns an error on Interix 3.5.
The main cause is Interix's readdir fills a false value in d_ino member
of struct dirent. gnulib's getcwd is checking for directory entries' ino
obtained from readdir against
86 matches
Mail list logo
