Re: MinGW-w64 fenv changes.

Bruno Haible writes: > When working on the floating-point code, one needs to have the hardware > specification handy. In this case, it is the > Intel® 64 and IA-32 Architectures Software Developer’s Manual > Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4 > (4700 pages) > > Then,

Re: MinGW-w64 fenv changes.

Hi Collin, > I can look at porting it but I have no knowledge of x86 floating point, Thanks for volunteering to handle this. When working on the floating-point code, one needs to have the hardware specification handy. In this case, it is the Intel® 64 and IA-32 Architectures Software Developer

Re: MinGW build on master broken by Gnulib update

Replying to the thread that started at . I agree with everything that Paul wrote in this thread, except for the typo where we wrote "MSVC port of Emacs" but meant "mingw port of Emacs". Eli Zaretskii replied to Paul Eggert: > >

Re: MinGW build on master broken by Gnulib update

> Date: Thu, 5 Sep 2024 11:49:19 -0700 > Cc: emacs-de...@gnu.org, luang...@yahoo.com > From: Paul Eggert > > On 2024-09-05 11:02, Eli Zaretskii wrote: > > > I'm talking about what's in the sig2str.h header. The above URL says > > nothing about it. Why cannot Gnulib arrange for that header to >

Re: mingw strtol bug

Hi Eric, > I ran into a mingw bug on strtol() today, and don't see it documented or > worked around in gnulib: Thanks for the report and test case. The functions strtoul(), strtoll(), strtoull() are equally affected. I'm adding workarounds to gnulib. 2021-04-02 Bruno Haible strtoul,

Re: mingw pollution of DATADIR vs. configmake.h [was: [libvirt] [PATCH v10 08/19] backup: Parse and output checkpoint XML]

Hi Eric, > unistd.in.h has: > > /* Get all possible declarations of gethostname(). */ > #if @GNULIB_GETHOSTNAME@ && @UNISTD_H_HAVE_WINSOCK2_H@ \ > && !defined _GL_INCLUDING_WINSOCK2_H > # define _GL_INCLUDING_WINSOCK2_H > # include > # undef _GL_INCLUDING_WINSOCK2_H > #endif When the applica

Re: mingw pollution of DATADIR vs. configmake.h [was: [libvirt] [PATCH v10 08/19] backup: Parse and output checkpoint XML]

[dropping libvirt list for now...] On 7/29/19 11:25 AM, Eric Blake wrote: > [adding bug-gnulib] > > On 7/24/19 12:55 AM, Eric Blake wrote: >> Add a new file checkpoint_conf.c that performs the translation to and >> from new XML describing a checkpoint. The code shares a common base >> class with

Re: MinGW compilation warning in fseeko

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, tim.rueh...@gmx.de > Date: Sat, 12 May 2018 20:40:46 +0200 > > I don't want to revert the #if, i.e. prefer fseeko64 to _fseeki64, because > the idea of mingw is to use the maximum of functions from the CRT DLLs. > > So I ended up adding the test for

Re: MinGW compilation warning in fseeko

Eli Zaretskii wrote: > > Do you know how to distinguish the two, just by preprocessor defines, > > without any autoconf test? > > AFAIK, it's tricky, because MinGW64 also defines __MINGW32__, and > doesn't have any macro specific to it that is defined by the compiler > itself. In Emacs we use thi

Re: MinGW compilation warning in fseeko

> From: Bruno Haible > Cc: Tim Rühsen > Date: Sat, 12 May 2018 14:31:59 +0200 > > > This is because configure-time test for _fseeki64 succeeds, but the > > prototype of _fseeki64 is not visible unless the condition > > > > _WIN32_WINNT >= 0x0600 > > > > holds > > According to > https://sou

Re: MinGW compilation warning in fseeko

Eli Zaretskii wrote: > While building the latest pretest of wget2 with mingw.org's MinGW, I > saw this warning: > >CC fseeko.lo > fseeko.c: In function 'fseeko': > fseeko.c:37:18: warning: implicit declaration of function '_fseeki64' > [-Wimplicit-function-declaration] >

Re: MinGW compilation warning in spawn-pipe.c

Eli Zaretskii wrote: > } > #define close nonintr_close > > IMO, it should use #undef before redefining 'close'. Yup. The file lib/pipe-filter-aux.h already contains this fix, but lib/spawn-pipe.c doesn't. 2018-05-12 Bruno Haible execute, spawn-pipe: Avoid warning about redefinin

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

> Cc: bug-gnulib@gnu.org > From: Paul Eggert > Date: Mon, 10 Oct 2016 08:07:35 -0700 > > Thanks, I installed that into Gnulib. Great, thanks a lot.

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

Thanks, I installed that into Gnulib.

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

> Cc: bug-gnulib@gnu.org > From: Paul Eggert > Date: Sun, 9 Oct 2016 11:07:46 -0700 > > Eli Zaretskii wrote: > > But because string.h was included, __STRING_H_SOURCED__ is defined, > > and MinGW's wchar.h doesn't define mbstate_t. Gnulib's wchar.h > > I suggest adding a __STRING_H_SOURCED__ che

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

Eli Zaretskii wrote: But because string.h was included, __STRING_H_SOURCED__ is defined, and MinGW's wchar.h doesn't define mbstate_t. Gnulib's wchar.h I suggest adding a __STRING_H_SOURCED__ check to Gnulib's lib/wchar.in.h's complicated test for the special invocation convention.

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

> Cc: bug-gnulib@gnu.org > From: Paul Eggert > Date: Sun, 9 Oct 2016 10:35:14 -0700 > > Eli Zaretskii wrote: > > I'm not sure I understand how this is different from what > > e.g. Gnulib's wchar.h already does. Can you point out the crucial > > differences? > > Ah, I didn't look at lib/wchar.in

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

Eli Zaretskii wrote: I'm not sure I understand how this is different from what e.g. Gnulib's wchar.h already does. Can you point out the crucial differences? Ah, I didn't look at lib/wchar.in.h. Yes, it's already doing that, with a complicated ifdef that is supposed to work on MinGW. It isn't

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

> From: Paul Eggert > Cc: bug-gnulib@gnu.org > Date: Sun, 9 Oct 2016 10:10:38 -0700 > > Eli Zaretskii wrote: > > I'm not sure what would be the best way of avoiding these errors > > The usual method is to alter the gnulib .h file so that it merely > include_next's > the system .h file when it

Re: MinGW compilation errors with Gnulib wchar.h and wctype.h

Eli Zaretskii wrote: I'm not sure what would be the best way of avoiding these errors The usual method is to alter the gnulib .h file so that it merely include_next's the system .h file when it detects that its partial inclusion is desired. Something like this: #ifdef __need_FILE # @INCLUDE

Re: mingw and AC_SYS_LARGEFILE

> From: Bruno Haible >> 2012-04-15  Bruno Haible  >> >>         Large File Support for native Windows platforms. > >I've pushed this patch now. > >Bruno Hi Bruno, I compiled the latest wget and gnulib modules in msys and wget mingw build is able to properly resume large files again. Thank yo

Re: mingw and AC_SYS_LARGEFILE

> 2012-04-15 Bruno Haible > > Large File Support for native Windows platforms. I've pushed this patch now. Bruno

Re: mingw and AC_SYS_LARGEFILE

Hi Paul, > I'd omit the comment These comments are necessary for maintenance. When I (or Eric or anyone else in the future) modifies this code, we need to know which piece of code applies to which platforms, so that 1. we don't waste time modifying code that has no influence on the platfor

Re: mingw and AC_SYS_LARGEFILE

Just some very minor comments about comments --- On 04/15/2012 09:57 AM, Bruno Haible wrote: > +#if _GL_WINDOWS_64_BIT_OFF_T > +# undef fseeko > +# if HAVE__FSEEKI64 /* msvc, mingw64 */ I'd omit the comment, which was inserted in multiple places, as I find it more distracting than helpful. It's

Re: mingw and AC_SYS_LARGEFILE

Bruno Haible wrote: >> 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? > > gl_LA

Re: mingw and AC_SYS_LARGEFILE

Hi Jim, > 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? gl_LARGEFILE is the macr

Re: mingw and AC_SYS_LARGEFILE

> the mingw64 headers provide a partial "Large File Support". > Namely, for > off_t >(lseek, ftruncate) >(fseeko, ftello) And even this partial support is only partially working. They define a function ftruncate64, and "#define ftruncate ftruncate64". This function 1) violates POSIX:

Re: mingw and AC_SYS_LARGEFILE

> My advice would be first to ask the currently active mingw development > group, namely the mingw64 project [5], whether they plan to add > "Large File Support" to their header files. It turns out, the mingw64 headers provide a *partial* "Large File Support". Namely, for off_t (lseek, ftrunc

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(),

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() - becaus

Re: mingw and AC_SYS_LARGEFILE

Hi, Ray Satiro wrote: > The gnulib fstat doc says: > "On platforms where off_t is a 32-bit type, stat may not correctly report the > size of files or block devices larger than 2 GB. The fix is to use the > AC_SYS_LARGEFILE macro. " > > Recently it was discovered that the latest versions of wget

Re: mingw: test-poll pipe part fails

On 06/30/2011 07:56 PM, Eric Blake wrote: > Yes, Windows pipes are that broken.:( > > Using socketpair is a possibly good idea, but I would do it on > libvirtd only. I don't know exactly how libvirtd uses this pipe, but > perhaps it can be changed to an eventfd-like abstraction that can be >

Re: mingw: test-poll pipe part fails

[adding libvirt] On 06/04/2011 12:24 AM, Paolo Bonzini wrote: > On Sat, Jun 4, 2011 at 00:37, Matthias Bolte > wrote: >> After testing a while and reading MSDN docs the problem seems to be >> that MsgWaitForMultipleObjects doesn't work on pipes. It doesn't >> actually wait but just returns immedi

Re: mingw flavours

Eric Blake explained on 2011-06-09: > > what's the difference between > > i686-pc-mingw32 and i686-w64-mingw32? > > i686-pc-mingw32 is the old mingw32 project; it is not as actively > maintained today, but is still the project used by cygwin. Right now, > it uses dwarf exceptions. > > i686-w64-m

Re: mingw: test-poll pipe part fails

On Sat, Jun 4, 2011 at 00:37, Matthias Bolte wrote: > After testing a while and reading MSDN docs the problem seems to be > that MsgWaitForMultipleObjects doesn't work on pipes. It doesn't > actually wait but just returns immediately. Digging MSDN and googling > about this suggest that there is no

Re: mingw: test-poll pipe part fails

2011/5/25 Matthias Bolte : > Output from a test run on mingw > > Unconnected socket test... passed > Connected sockets test... passed > General socket test with fork... passed > Pipe test... failed (expecting POLLHUP after shutdown) > FAIL: test-poll.exe > > This affects the attempt to make libvirt

Re: mingw: test-ftell and test-ftello assertion failures

On 05/25/2011 02:37 PM, Matthias Bolte wrote: > In both tests ASSERT (ftell (stdin) == -1); in line 45 fails. ftell > (stdin) returns 0 in this case. > > Found via libvirt on mingw with recent gnulib version: > f4c4af09bcf3f0497dc3347ecc0a0b3c9ee1ff63 In this particular case, test-ftell.sh is cal

RE: MinGW-w64 Compatibility

> This is one of the reasons why I ask for a reproducible sample. If that sample > fails for you but works for other people, it would be an indication of > something peculiar with your setup. If that sample fails also for someone > who has experience with gnulib, that person can investigate it. I

Re: MinGW-w64 Compatibility

David Hoyt wrote: > I've had the same issue compiling gnutls ... > Could be there's something wrong w/ my setup (but I don't think so). This is one of the reasons why I ask for a reproducible sample. If that sample fails for you but works for other people, it would be an indication of something pe

RE: MinGW-w64 Compatibility

Bruno Haible wrote: > Can you please provide a minimal reproducible sample? That is, can you > give an input file that, when compiled with gnulib's , yields > an error? Also, please show the compiler command-line, and the error that > you get. Everyone's blaming someone else, so I honestly don't k

Re: MinGW-w64 Compatibility

Hello, David Hoyt wrote: > A build using the latest from MinGW-w64 fails with a redefinition error b/c > it finds socklen_t in two places. Configure finds both winsock2.h and > ws2tcipip.h and when it finds winsock.h, it does a "typedef int socklen_t" > in gl/sys_socket.in.h but this is already de

Re: mingw, ptw32, and struct timespec

Eric Blake wrote: > On 06/02/2010 10:50 AM, Eric Blake wrote: >> I'm getting a compilation failure when trying to cross-compile from >> Linux to mingw, because I have the mingw pthreads-win32 (ptw32) library >> installed (Fedora 13 system, with mingw32-pthreads and mingw32-gcc >> packages). The p

Re: mingw, ptw32, and struct timespec

On 06/02/2010 10:50 AM, Eric Blake wrote: > I'm getting a compilation failure when trying to cross-compile from > Linux to mingw, because I have the mingw pthreads-win32 (ptw32) library > installed (Fedora 13 system, with mingw32-pthreads and mingw32-gcc > packages). The ptw32 library installs a p

Re: mingw alternatives

On 04/26/2010 10:45 AM, Bruno Haible wrote: Paolo Bonzini wrote: We're at the point where every other function in mingw is being hooked. Maybe it would be better to start fresh with ReactOS's msvcrt, add everything that gnulib provides and more (for example the *at functions could be added very

Re: mingw alternatives

Paolo Bonzini wrote: > We're at the point where every other function in mingw is being hooked. > > Maybe it would be better to start fresh with ReactOS's msvcrt, add > everything that gnulib provides and more (for example the *at functions > could be added very easily), and link it statically wi

Re: mingw and same-inode

Eric Blake wrote: > According to Jim Meyering on 9/25/2009 5:59 AM: >> When I see the tentacles of this change reaching so deeply into the core >> of gnulib and coreutils, I have to question whether it is worthwhile >> to accommodate mingw's lack of inode numbers. >> >> Opinions? > > Raise this iss

Re: mingw and same-inode

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/25/2009 5:59 AM: > When I see the tentacles of this change reaching so deeply into the core > of gnulib and coreutils, I have to question whether it is worthwhile > to accommodate mingw's lack of inode numbers. > > Opini

Re: mingw and same-inode

Eric Blake wrote: > According to Jim Meyering on 9/24/2009 12:29 AM: >> bool same = false; >> ... >> same = SAME_INODE (source_dir_stats, dest_dir_stats); >> if (same < 0) >> same = (identical_basenames >> && strcmp (source_basename, dest_basename) == 0); > >

Re: mingw and same-inode

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/24/2009 12:29 AM: > bool same = false; > ... > same = SAME_INODE (source_dir_stats, dest_dir_stats); > if (same < 0) > same = (identical_basenames > && strcmp (source_basename, dest

Re: mingw and same-inode

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/24/2009 12:29 AM: >> I'm also preparing a followup patch for coreutils usage of SAME_INODE. >> Thoughts before I apply this? > > You have pushed these changes already. > Imagine my surprise upon seeing unreviewed and una

Re: mingw and same-inode

If the tri-state test is required in only a few places, how about using a new macro, say SAME_INODE_TRISTATE, I suggest SAME_INODE_STRICT, and agree in general with Jim's email. Paolo

Re: mingw and same-inode

Eric Blake wrote: > I'm currently testing these two patches, as mingw prerequisites before I can > get linkat() working. In particular, mingw is lousy at SAME_INODE, since all > three of [fl]stat produce st_ino == 0 for all files (then again, mingw never > claimed POSIX compliance!). Code was alw

Re: mingw remove bug

Eric Blake wrote: > Jim Meyering meyering.net> writes: > >> > Meanwhile, the rmdir-errno module, in use by coreutils until today, guessed >> > wrong for cross-compilation to Solaris (where rmdir fails with EEXIST, not >> > ENOTEMPTY, on a populated directory); now that coreutils no longer uses th

Re: mingw remove bug

Jim Meyering meyering.net> writes: > > Meanwhile, the rmdir-errno module, in use by coreutils until today, guessed > > wrong for cross-compilation to Solaris (where rmdir fails with EEXIST, not > > ENOTEMPTY, on a populated directory); now that coreutils no longer uses the > > module [1], I see n

Re: mingw remove bug

Eric Blake wrote: > Eric Blake byu.net> writes: >> > I'm arguing that the second program should also report "No such >> > file or directory". >> >> Ah, so for 'foo/', the code should distinguish between ENOENT and ENOTDIR, >> based on whether 'foo' exists. I'll update the patch and test according

Re: mingw remove bug

Eric Blake byu.net> writes: > > I'm arguing that the second program should also report "No such > > file or directory". > > Ah, so for 'foo/', the code should distinguish between ENOENT and ENOTDIR, > based on whether 'foo' exists. I'll update the patch and test accordingly. I'm taking a step

Re: mingw remove bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ben Pfaff on 9/14/2009 8:42 PM: > > I'm arguing that the second program should also report "No such > file or directory". Ah, so for 'foo/', the code should distinguish between ENOENT and ENOTDIR, based on whether 'foo' exists. I'll upd

Re: mingw remove bug

Eric Blake writes: > According to Ben Pfaff on 9/14/2009 5:51 PM: >>> + /* Mingw remove("file/") fails with EINVAL, instead of the required >>> + ENOTDIR. */ >>> + if (ISSLASH (name[len - 1])) >>> +{ >>> + errno = ENOTDIR; >>> + return -1; >>> +} >> >> I believe that thi

Re: mingw remove bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ben Pfaff on 9/14/2009 5:51 PM: >> + /* Mingw remove("file/") fails with EINVAL, instead of the required >> + ENOTDIR. */ >> + if (ISSLASH (name[len - 1])) >> +{ >> + errno = ENOTDIR; >> + return -1; >> +} > > I b

Re: mingw remove bug

Eric Blake writes: > + if (lstat (name, &st) == 0 && S_ISDIR (st.st_mode)) > +{ > + /* Mingw rmdir("empty/.") mistakenly succeeds. */ > + while (ISSLASH (name[len - 1])) > +len--; > + if (name[len - 1] == '.' && (1 == len || ISSLASH (name[len - 2]))) > +{ > +

Re: mingw test cleanups

Eric Blake wrote: > But my shortcut > is generally adequate enough to shave time and limp by with a single step > instead of two (it is already time-consuming enough to use gnulib-tool on > cygwin, due to slow forks). gnulib-tool is there to make your life easier. So, you would probably like it to

Re: mingw test cleanups

Eric Blake wrote: > > EOPNOTSUPP is an error code related to sockets. I also see it sometimes on > > NFS mounts. POSIX [1] describes it as "Operation not supported on socket". > > Probably ENOSYS ("Function not supported.") is a better error code. > > ENOSYS does make more sense (even though POSIX

Re: mingw test cleanups

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 9/6/2009 11:27 AM: >> $ cross_compiling=yes gl_cv_func_open_slash=no CC='gcc -mno-cygwin' \ >>CFLAGS='-Wall -gdwarf-2' ./gnulib-tool --with-tests --test canonicalize >> ... >> for the situation where AC_CANONICAL_HOST i

Re: mingw test cleanups

Hi Eric, > I will be pushing these later today as prerequisites to fixing fchdir and > splitting fdopendir into its own module. This series avoids some compilation > warnings due to missing chmod on mingw, and allows me to run gnulib > testsuites > under cygwin while cross-compiling to mingw:

Re: mingw test cleanups

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 8/31/2009 10:47 AM: >> I will be pushing these later today as prerequisites to fixing fchdir and >> splitting fdopendir into its own module. This series avoids some compilation >> warnings due to missing chmod on mingw, an

Re: mingw test cleanups

Eric Blake wrote: > I will be pushing these later today as prerequisites to fixing fchdir and > splitting fdopendir into its own module. This series avoids some compilation > warnings due to missing chmod on mingw, and allows me to run gnulib testsuites > under cygwin while cross-compiling to ming

Re: mingw and execute vs. posix_spawn

Eric Blake wrote: > @@ -44,7 +44,7 @@ dup_noinherit (int fd) > (DWORD) 0, /* DesiredAccess */ > FALSE, /* InheritHandle */ > DUPLICATE_SAME_ACCESS)) /* Options */ > -error (EXIT_FAILURE,

Re: mingw and execute vs. posix_spawn

Eric Blake wrote: > Even though execute, pipe, and wait-process work just fine on mingw, the fact > that they pull in a dependency on posix_spawn on all other platforms means > that > the build attempts to compile files, like lib/spawni.c or test-posix_spawn.c > that cause failures on mingw. O

Re: mingw and execute vs. posix_spawn

Eric Blake wrote: > * lib/execute.c (execute) [_MSC_VER || __MINGW32__]: Avoid > compiler warning about incompatible types. > * lib/pipe.c (create_pipe) [_MSC_VER || __MINGW32__]: Likewise. Applied as follows: 2009-03-06 Eric Blake * lib/execute.c (execute) [WIN32_NATIVE]: Cast argum

Re: mingw: pwd.h and grp.h functions, uid_t, getuid, chown, fork, etc

Hi Simon, > Generally, I think it would be nice to identify all modules that doesn't > work under mingw yet. Last time I checked, I needed --avoid=savewd --avoid=mkancesdirs --avoid=mkdir-p --avoid=getugroups --avoid=idcache --avoid=userspec in order to get a successful build on mingw. Your au

Re: mingw and SIGPIPE, new modules 'sigpipe' and 'write'

Bruno Haible <[EMAIL PROTECTED]> writes: > I'm applying this in 7 commits. It appears to solve the problem for sigpipe-die, see successful mingw build of it in: http://autobuild.josefsson.org/gnulib/log-200809261431057164000.txt I'll get around to look at the other failed modules on mingw in tw

Re: mingw and SIGPIPE, new modules 'sigpipe' and 'write' (7/7)

2008-09-26 Bruno Haible <[EMAIL PROTECTED]> * modules/sigpipe-die (Depends-on): Add sigpipe. *** modules/sigpipe-die.orig2008-09-26 12:52:18.0 +0200 --- modules/sigpipe-die 2008-09-26 04:09:29.0 +0200 *** *** 9,14 --- 9,15 error gettext-h

Re: mingw and SIGPIPE, new modules 'sigpipe' and 'write' (6/7)

2008-09-26 Bruno Haible <[EMAIL PROTECTED]> * lib/stdio.in.h (fprintf, vfprintf, printf, vprintf, fputc, putc, putchar, fputs, puts, fwrite): Replace when REPLACE_STDIO_WRITE_FUNCS and GNULIB_STDIO_H_SIGPIPE are set. * lib/stdio-write.c: New file. * m4/std

Re: mingw and SIGPIPE, new modules 'sigpipe' and 'write' (5/7)

2008-09-26 Bruno Haible <[EMAIL PROTECTED]> * modules/safe-write (Depends-on): Add write. *** modules/safe-write.orig 2008-09-26 12:52:18.0 +0200 --- modules/safe-write 2008-09-26 01:25:18.0 +0200 *** *** 8,13 --- 8,14 Depends-on: safe-r

Re: mingw and SIGPIPE, new modules 'sigpipe' and 'write' (4/7)

2008-09-26 Bruno Haible <[EMAIL PROTECTED]> * modules/sigpipe-tests: New file. * tests/test-sigpipe.c: New file. * tests/test-sigpipe.sh: New file. === modules/sigpipe-tests == Files: tests/test-sigpipe.c tests/test-sigpipe

Re: mingw and SIGPIPE, new modules 'sigpipe' and 'write' (3/7)

2008-09-26 Bruno Haible <[EMAIL PROTECTED]> * modules/write: New file. * lib/unistd.in.h: Include . (write): New declaration. * lib/write.c: New file. * m4/write.m4: New file. * m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS): Initialize GNULIB_UNIST

Re: mingw and SIGPIPE, new modules 'sigpipe' and 'write' (2/7)

2008-09-26 Bruno Haible <[EMAIL PROTECTED]> * lib/signal.in.h (SIGPIPE): Define to a replacement value. (raise): New declaration. * lib/sigprocmask.c (SIGPIPE_handler): New variable. (ext_signal): New function. (rpl_raise): New function. * m4/signa

Re: mingw and SIGPIPE, new modules 'sigpipe' and 'write' (1/7)

2008-09-26 Bruno Haible <[EMAIL PROTECTED]> * modules/sigpipe: New file. * m4/sigpipe.m4: New file. modules/sigpipe == Description: Emulation of POSIX compatible SIGPIPE behaviour. Files: m4/sigpipe.m4 Depends-on: si

Re: mingw fopen bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 9/23/2008 5:25 AM: >> In an effort to unify this behavior, I was considering making m4 1.4.12 >> pre-reject directories with EISDIR > > Then I would split the fopen() call into open() + fdopen(), and use fstat() > between

Re: mingw fopen bug

Eric Blake wrote: > The use case where I discovered this bug was with m4 1.4.11. Compare: > > mingw$ m4 . > m4.exe: .: Permission denied > Linux$ m4 . > m4:/:1: Read error > OpenBSD$ m4 . && echo done > done > EMX$ m4 . > > > In an effort to unify this behavior, I was considering making m4 1.4.

Re: mingw fopen bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 9/22/2008 6:15 PM: > But fopen() on a directory? Who does that? If no-one needs that, I would be > satisfied with mentioning the problem under "Portability problems not fixed by > Gnulib" in the doc. The use case where I d

Re: mingw fopen bug

Hi Eric, Eric Blake wrote: > Adding such a workaround would allow code like this to work on mingw: > > FILE *f = fopen (".", "r"); > DIR *d = fdopendir (fileno (f)); > readdir (d); I understand the heavy use of fdopendir() in coreutils: on those systems which implement this function natively, it

Re: mingw

Hi Eric, Eric Blake wrote: > Actually, in the latest version of mingw, you have the option to use a > more POSIX compliant [printf] instead of being stuck with MSVCRT's flaws: > http://cygwin.com/ml/cygwin-announce/2008-09/msg8.html Interesting... But I think gnulib should continue to be deve

Re: mingw bug and localename

> #define SUBLANG_TIBETAN_PRC0x01 > #define SUBLANG_TIBETAN_BHUTAN 0x01 > > So the fail is explained: both sublanguage codes has the same > value. Thanks for reporting it. I don't know how long time the mingw guys will need to fix their problem, so I'm applying t

Re: mingw bug and localename

Hi Jose, > /* Mingw headers don't have latest language and sublanguage codes. */ > ... > # ifndef SUBLANG_TIBETAN_PRC > # define SUBLANG_TIBETAN_PRC 0x01 > # endif > # ifndef SUBLANG_TIBETAN_BHUTAN > # define SUBLANG_TIBETAN_BHUTAN 0x02 > ... > #endif > > Then these constants are used in severa

Re: mingw isnanl-nolibm failure

Eric Blake wrote on 2007-12-11: > 2007-12-11 Eric Blake <[EMAIL PROTECTED]> > > + Fix bug with -0.0L in previous patch. > + * lib/isnan.c (rpl_isnanl): Make robust to -0.0L and pad bits. > + * tests/test-isnan.c (main): Also test on zeroes. > + * tests/test-isnanf.c (main): Lik

Re: mingw and memcmp

Bruno Haible <[EMAIL PROTECTED]> writes: > - You can bury the 'memcmp' module. It's not needed by ANSI C systems, > and gnulib assumes ANSI C for ca. 2 years already. I think we're assuming freestanding C89 or better, right? memcmp is required for hosted C89, but not for freestanding. It's

m4 and progname (was: Re: mingw and memcmp)

Eric Blake wrote: > (I'm starting to wonder if it is easier to require all test-foo.c programs to > declare and populate program_name themselves, rather than relying on the > progname module.) Oh no. The progname module is there to simplify things for both programs and test suite. It would be b

Re: mingw and memcmp

Hi Eric, > +2007-12-20 Eric Blake <[EMAIL PROTECTED]> > + > + Work around circular library issue when cross-compiling. > + * lib/progname.c (set_program_name): Use strncmp, not memcmp, so > + that progname.o does not need to pull in rpl_memcmp. I don't like this patch at all.

Re: mingw isnanl-nolibm failure

Eric Blake byu.net> writes: > > Here's one idea. Since it fixes the mingw cross-compilation failure of test- > isnanl-nolibm, I'm installing it; if we come up with something better or more > efficient in the future, we can alter the test then. > > The idea behind this patch is that = doesn't

Re: mingw isnanl-nolibm failure

Bruno Haible clisp.org> writes: > Ack. It's a bug in the isnanl module. > > > I'm not sure how to fix this, but it seems like rpl_isnanl needs to check for > > invalid x86 long double bit patterns before falling back to ==. > > Either this, or ensure that the "checking where to find the expon

Re: mingw isnanl-nolibm failure

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 12/7/2007 4:19 AM: > > Either this, or ensure that the "checking where to find the exponent" tests > return the bit positions instead of "unknown". > > But I don't see how to implement either of these two possible fixes f

Re: mingw isnanl-nolibm failure

Eric Blake wrote: > When compiling natively on mingw: > ... > checking where to find the exponent in a 'long double'... word 2 bit 0 > checking where to find the exponent in a 'long double'... (cached) word 2 bit > 0 > > and the resulting rpl_isnanl works. > > But when cross-compiling: > ... > ch

Re: mingw frexp failure

Eric Blake wrote: > When compiling natively: > > checking whether frexp() can be used without linking with libm... yes > checking whether frexp works... no > > The failure is with +inf, where frexp mistakenly returns NaN instead of > inf. > > But when cross-compiling, mingw was omitted from the lis

Re: mingw and isnanl

Eric Blake wrote: > The problem is not a native compile, but a cross-compile ... I guess my > original complaint should have made that more explicit. Indeed. It was hard to guess so, while you were talking about failed tests and 'fpclassify' results :-) > configure:15398: checking whether isnanl

Re: mingw and isnanl

Bruno Haible clisp.org> writes: > > Eric Blake wrote: > > gnulib's test-isnanl currently dies on mingw > > I don't observe this. Just did a > >./gnulib-tool --create-megatestdir --dir=/dev/shm/testdir1 --with-tests \ > isnan-nolibm isnanl-nolibm isnanl vasnprintf-posix >

Re: mingw and isnanl

Eric Blake wrote: > gnulib's test-isnanl currently dies on mingw I don't observe this. Just did a ./gnulib-tool --create-megatestdir --dir=/dev/shm/testdir1 --with-tests \ isnan-nolibm isnanl-nolibm isnanl vasnprintf-posix configured it on mingw (msys), and all tests pass. No

Re: mingw lseek bug

Eric Blake wrote: > Do we want to offer ftello(fp) as the shorter alternative to > lseek(fileno(fp),0,SEEK_CUR) for testing seekability? I don't think we can guarantee that, if we stick to the abstractions laid out by POSIX. The ftello.html page says "The ftell() function shall obtain the curr

new module 'ftell' (was: Re: mingw lseek bug)

Eric Blake wrote: > --- doc/functions/ftell.texi 1 May 2007 15:11:38 - 1.1 > +++ doc/functions/ftell.texi 24 May 2007 16:21:36 - > @@ -4,10 +4,12 @@ > > POSIX specification: @url{http://www.opengroup.org/susv3xsh/ftell.html} > > -Gnulib module: --- > +Gnulib module: ftello >

Re: mingw lseek bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 5/28/2007 7:55 AM: > Thanks for explaining. I thought you were talking about the lseek call > inside fflush, not about an lseek call before it. > > Since loss of data is a severe condition, I'm adding a note about it: Tha

  1   2   >