Unable to override value of AR set by gnulib macro?
GNU Octave's configure script used to allow users to set AR using ./configure AR=... but that stopped working recently. It looks like the problem is the following change to gnulib: http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=2b14869442bce932cf1d805387928484d4914d59 Since this change was intended to improve support for Minix, could it at least be limited to Minix systems? Maybe I'm missing something, but it seems to me that it would be better to allow the user to set AR and ARFLAGS from the environment and only set default values if these variables are not already set. jwe
[PATCH] freopen SEGFAULT on win32 with filename == NULL
Hi.
When calling
freopen(NULL, mode, stream);
on MS Windows using MinGW segfaults because it tries to strcmp(NULL,
"/dev/null")... *ouch*
--- freopen.c.orig 2011-08-03 14:22:15 +0200
+++ freopen.c 2011-08-25 21:01:46 +0200
@@ -38,7 +38,7 @@
rpl_freopen (const char *filename, const char *mode, FILE *stream)
{
#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
- if (strcmp (filename, "/dev/null") == 0)
+ if (filename && strcmp (filename, "/dev/null") == 0)
filename = "NUL";
#endif
Furthermore, using NULL as filename does not work at all using the MS
C runtime library (debug assertion violation).
--- freopen.c.1 2011-08-25 21:05:34 +0200
+++ freopen.c 2011-08-25 21:08:52 +0200
@@ -38,6 +38,9 @@
rpl_freopen (const char *filename, const char *mode, FILE *stream)
{
#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
+# ifdef _MSC_VER
+ if (!filename) return NULL; /* would trigger a runtime error on MSVC */
+# endif
if (filename && strcmp (filename, "/dev/null") == 0)
filename = "NUL";
#endif
Using MinGW and trying to change stdout's mode to binary simply fails:
if (!isatty(fileno(stdout))
freopen(NULL, "wb", stdout); /* <- returns NULL */
Would it be feasible to use the _setmode function in rpl_freopen
instead of freopen if the filename == NULL on win32 (non-cygwin)?
What about the fsetbinary, xfchangemode functions discussed here
[http://lists.gnu.org/archive/html/bug-gnulib/2010-03/msg00111.html]?
Cheers,
--
Claudio
Re: ylwrap in gnulib/build-aux?
On 08/25/2011 12:30 PM, Karl Berry wrote: However, the finicky gnulib hook declines to install it, due to space/tab madness. Can someone fix this in the automake sources and I'll try again? > build-aux/ylwrap:140: space before tab in indent. > + from="y_tab.c" Space-tab indentation? How awkward! It is now fixed in automake, if you want to retry setting up the gnulib sync. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: ylwrap in gnulib/build-aux?
But Eric's argument from [1], the ability to get the newest version between Automake releases, [1] http://lists.gnu.org/archive/html/bug-gnulib/2009-03/msg00175.html Yes. However, the finicky gnulib hook declines to install it, due to space/tab madness. Can someone fix this in the automake sources and I'll try again? Thanks, karl build-aux/ylwrap:140: space before tab in indent. + from="y_tab.c" build-aux/ylwrap:142: space before tab in indent. + if test $from = "y.tab.h"; then build-aux/ylwrap:143: space before tab in indent. + from="y_tab.h" build-aux/ylwrap:144: space before tab in indent. + fi build-aux/ylwrap:151: space before tab in indent. + [\\/]* | ?:[\\/]*) target="$2";; build-aux/ylwrap:152: space before tab in indent. + *) target="../$2";;
Re: _GL_UNISTD_H & _GL_INCLUDING_WINSOCK2_H
> * Sam Steingold [2011-08-25 12:09:34 -0400]: > > .../modules/rawsock/rawsock.c:691:3: warning: implicit declaration of > function `close_used_without_including_unistd_h' the immediate cause appears to be that I include unistd.h after some other headers (specifically, #include #include #include #include #include ) and then it bails out. are you sure this is right?! -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://jihadwatch.org http://ffii.org http://mideasttruth.com http://iris.org.il http://truepeace.org http://www.PetitionOnline.com/tap12009/ If you're being passed on the right, you're in the wrong lane.
_GL_UNISTD_H & _GL_INCLUDING_WINSOCK2_H
Hi, gllib/unistd.h says: #if 1 && 1 \ && !defined _GL_INCLUDING_WINSOCK2_H # define _GL_INCLUDING_WINSOCK2_H # include # undef _GL_INCLUDING_WINSOCK2_H #endif #if !defined _GL_UNISTD_H && !defined _GL_INCLUDING_WINSOCK2_H #define _GL_UNISTD_H so when compiling with i686-pc-mingw32-gcc _GL_INCLUDING_WINSOCK2_H is undef'ed and so _GL_UNISTD_H is __NOT__ defined thus I get .../modules/rawsock/rawsock.c:691:3: warning: implicit declaration of function `close_used_without_including_unistd_h' why? -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://openvotingconsortium.org http://truepeace.org http://www.memritv.org http://mideasttruth.com http://ffii.org http://iris.org.il http://camera.org What garlic is to food, insanity is to art.
