On 9/23/2011 4:10 PM, jojelino wrote:
> It fixed the relocation problem. but led performance issue :(
>
> $ time id > /dev/null
>
> real0m0.141s
> user0m0.000s
> sys 0m0.000s
Well, the libiconv distributed as an official cygwin package *SHOULD*
not have been built with --enable-reloc
On MSVC 9, does not pre-exist, gnulib defines it. I get a syntax
error in the declaration of strncasecmp(), because size_t is not defined.
This fixes it:
2011-09-25 Bruno Haible
strings: Fix compilation error on MSVC.
* lib/strings.in.h: Include for size_t.
--- lib/strings.
Did you see http://bugs.python.org/issue4804 ?
Particularly http://bugs.python.org/file12953/__pioinfo.patch
A little bit hackhish but seems to work
Thanks
bastien
On Sun, Sep 25, 2011 at 11:30 PM, Bruno Haible wrote:
>> + * The default way, which is reasonable for programs (not libraries
> + * The default way, which is reasonable for programs (not libraries):
> + AC_DEFINE([MSVC_INVALID_PARAMETER_HANDLING], [DEFAULT_HANDLING])
> +
> + * The way for libraries that make "hairy" calls (like close(-1), or
> + fclose(fp) where fileno(fp) is closed, or simply getdtabl
On MSVC, it is not only possible to install, through
_set_invalid_parameter_handler, a handler that transfers control to a point
where the program (in this case, gnulib) can provide a sensible return value
or error return to a particular function.
It is also possible to install a handler that does
> 1) Install the handler once, globally.
> 2) Allocate the jmp_buf per thread.
Here comes part 2.
2011-09-25 Bruno Haible
msvc-inval: Make handler multithread-safe.
* lib/msvc-inval.h (struct gl_msvc_inval_per_thread): New type.
(gl_msvc_inval_restart, gl_msvc_inv
There is one copy of the "invalid parameter handler" in the MSVC runtime
library; there is not one copy per thread. Therefore, setting this handler
or deinstalling it in a gnulib function is not multithread-safe. For MT-safety
the module needs two changes:
1) Install the handler once, globally.
On 09/25/2011 07:29 PM, Bruno Haible wrote:
Hi Nikos,
I got some bug report [0] on gnutls that on MacOSX gnutls compilation
fails with the following error.
serv.c:1236: warning: cast to pointer from integer of different size
In file included from ./../gl/unistd.h:112,
from ./../gl/stdlib.h:
Hi Nikos,
> I got some bug report [0] on gnutls that on MacOSX gnutls compilation
> fails with the following error.
>
> serv.c:1236: warning: cast to pointer from integer of different size
> In file included from ./../gl/unistd.h:112,
> from ./../gl/stdlib.h:90,
> from udp-serv.c:5:
> ./../gl/
On 09/25/11 09:29, Nikos Mavrogiannopoulos wrote:
> [0]. https://savannah.gnu.org/support/?107806
I suggest debugging this in the context of the gnutls
distribution itself, without particularly worrying about
gnulib. The serv.c bug doesn't have any apparent connection
to gnulib, for example. Fo
And this is a quick review about the new documentation ...
On Thursday 22 September 2011, Gary V wrote:
>
> @node Bootstrap
> @chapter Bootstrap
>
> The process of executing the various tools required to bring all the
> generated files up to date in a directory freshly checked out from
> source c
On 09/25/11 09:35, Bruno Haible wrote:
> AC_PROG_CC_C99 should then be preferred over AC_PROG_CC_STDC. Right?
No, because one cannot safely mix
AC_PROG_CC_C99 and AC_PROG_CC_STDC, just
as one cannot safely mix AC_PROG_CC_STDC
and AC_PROG_CC_C89, or safely mix
AC_PROG_CC_C89 and AC_PROG_CC_C99.
Pe
On 09/25/11 02:30, Bruno Haible wrote:
> It's good and normal programming style to add 'inline' in front of
> all static functions that are only used once in the compilation unit.
This is not a style that I'm familiar with or comfortable with.
It reminds me of people putting "register" in front of
Paul Eggert wrote:
> if a Gnulib module requires a reasonably
> up-to-date C compiler, it might be a good idea for the module
> to AC_REQUIRE([AC_PROG_CC_STDC]).
What is the difference between AC_PROG_CC_STDC and AC_PROG_CC_C99?
As I understand it, AC_PROG_CC_STDC is a "moving target", whereas
AC_
Hello,
I got some bug report [0] on gnutls that on MacOSX gnutls compilation
fails with the following error.
serv.c:1236: warning: cast to pointer from integer of different size
In file included from ./../gl/unistd.h:112,
from ./../gl/stdlib.h:90,
from udp-serv.c:5:
./../gl/getopt.h:197: error
On 09/25/11 06:25, Pádraig Brady wrote:
> If doing this in gnulib we should also remove the
> -Wdeclaration-after-statement from m4/manywarnings.m4
Good point. Also, if a Gnulib module requires a reasonably
up-to-date C compiler, it might be a good idea for the module
to AC_REQUIRE([AC_PROG_CC_ST
On Thursday 22 September 2011, Gary V wrote:
> Anyone:
>
> It's beginning to look as though all this work is, once again, in very
> real danger of just slipping quietly through the cracks.
>
Hi Gary. While I don't pretend to really understand the scope and purposes
of your script, I might anyway
On 09/25/2011 09:14 AM, Gary V. Vaughan wrote:
> Hi Paul,
>
> On 25 Sep 2011, at 13:09, Paul Eggert wrote:
>
>> On 09/24/11 22:31, Gary V. Vaughan wrote:
>>> $ cc -o hello hello.c
>>> cc-1241 cc: ERROR File = hello.c, Line = 7
>>> A declaration cannot appear after an executable statement in a bl
> 2011-09-22 Bruno Haible
>
> strerror_r-posix: Avoid a link error on MSVC.
> * m4/strerror_r.m4 (gl_PREREQ_STRERROR_R): Check for snprintf.
> * lib/strerror_r.c (snprintf): Define to _snprintf if it doesn't exist.
Oops, that fixed the link error, but at the cost of a test su
The chsize() function also crashes for invalid fd on MSVC 9. This works around
it.
We don't need to make the fixed chsize() function public, since the POSIX API
for this functionality is ftruncate().
2011-09-25 Bruno Haible
ftruncate: Support for MSVC 9.
* lib/ftruncate.c: In
Simon Josefsson wrote:
Once the copyright papers are resolved, I can commit it
> unless someone else beats me to it.
Hi. The copyright should be solved now. I've attached the patch for the
base32 module again. (I've changed the RFC reference to point to the
newest version.)
Thanks, Gijs
>Fr
fstat() also crashes on MSVC 9 for an invalid fd argument. This, together with
the need to use 'largefile' whenever there is an fstat() call of a file that
could be large than 2 GB, is enough justification for a new module 'fstat'.
2011-09-25 Bruno Haible
New module 'fstat'.
*
On MSVC 9, I get a compilation error in linkat.c, because does not
exist.
Should that include be removed, or should a module dependency to 'stdint' be
added?
The #include in this file was added on 2009-10-06, because of
SIZE_MAX. But that use of SIZE_MAX was subsequentlyr removed on 2009-10-07.
On MSVC 9, it's the code from lib/fclose.c which makes fclose(stdout) crash:
if (close (fd) < 0 && saved_errno == 0)
saved_errno = errno;
fclose (fp); /* will fail with errno = EBADF, if we did not lose a race */
Here's the fix.
2011-09-25 Bruno Haible
fclose: Support
Paul Eggert wrote:
> >> * Why does dup2.c need to use 'inline'?...
> >
> > Do you know the optimizing behaviour of MSVC, or are you making assumptions?
>
> It's the other way around, no? If we don't know the optimizing
> behavior then we should omit "inline".
I disagree. It's good and normal
Hi Paul,
On 25 Sep 2011, at 13:09, Paul Eggert wrote:
> On 09/24/11 22:31, Gary V. Vaughan wrote:
>> $ cc -o hello hello.c
>> cc-1241 cc: ERROR File = hello.c, Line = 7
>> A declaration cannot appear after an executable statement in a block.
>
> You're supposed to use cc's -c99 flag, no?
> Or c
26 matches
Mail list logo
