On Nov 24, 2010, at 22:07 , ext Paul Eggert wrote:
> I pushed the following patch; could you please give it a try?
> I don't have an OSX host to test it on. Thanks.
The patch works, tested with 64-bit compile with GCC 4.2.
Thanks,
Jarno
>
> From 531b8a416b6ae40f89808e1db8976eb25972e661 Mon
On 11/27/10 00:59, Ralf Wildenhues wrote:
> Should this patch have a similar pendant for the AC_TYPE_INT64_T macro
> in Autoconf?
Offhand I would say not, since that macro tests for int64_t
individually, whereas the problem in gnulib is that all of
stdint.h was being tested collectively. But perh
On 12/02/10 12:13, Ludovic Courtès wrote:
> I’d like to use ‘nproc’ in libguile, which is LGPLv3+. Could you change
> the license accordingly?
nproc does feel quite libraryish and it'd be fine with me.
Bruno has contributed the most to it lately, though, and
I'd value his opinion.
The recent coreutils sort bug related to threading made me take a look
at gnulib for similar issues. When you try to use gnulib in threaded
code, any process-global state can potentially cause problems, whether
that be static data, file descriptor state, current directory, umask,
etc. For a lot o
Paul Eggert wrote:
> > I’d like to use ‘nproc’ in libguile, which is LGPLv3+. Could you change
> > the license accordingly?
>
> nproc does feel quite libraryish and it'd be fine with me.
Yes, nproc is libraryish, comparable to parts of the contents of libgomp.
Therefore it's fine with me too. I
[adding bug-gnulib, thanks to some issues with 'make syntax-check' in
gnulib-provided files]
On 12/02/2010 02:25 AM, Kenneth Nagin wrote:
>>> > I am receiving syntax error when compiling libvirt-0.8.5.
>>> > However, make without syntax-check completes successfully.
>>> >
>>> > check_author_list
On 12/02/10 13:47, Ralf Wildenhues wrote:
> * error_at_line.c ...
> IMVHO it makes sense to at least document the requirement for the caller
> here.
Yes. This is also a restriction for the glibc implementation, no?
So it's fine if gnulib has the same restriction.
> * in getloadavg.c, getloadavg
Hi Ralf,
> When you try to use gnulib in threaded
> code, any process-global state can potentially cause problems, whether
> that be static data, file descriptor state, current directory, umask,
> etc. For a lot of these data and in a lot of the cases, gnulib is safe.
> Still, it might make sense
Bruno Haible writes:
> I would find it useful and systematic if we started to add a
> section "Multithreading:" to the module descriptions. Its contents
> could be a simple statement like "MT-safe", or a description like
> this for iconv_open:
> A conversion descriptor can not be used in multip
Hi Bruno,
Bruno Haible wrote:
> You're just scratching the surface. More importantly, the 'alloca'
> module cannot be used _at_all_ in code meant to be used in multiple
> threads.
> 1. because the stack size for threads is often smaller than
> the stack size of the main thread. (16 KB vs. 8
* Paul Eggert wrote on Fri, Dec 03, 2010 at 01:39:19AM CET:
> On 12/02/10 13:47, Ralf Wildenhues wrote:
>
> > * error_at_line.c ...
> > IMVHO it makes sense to at least document the requirement for the caller
> > here.
>
> Yes. This is also a restriction for the glibc implementation, no?
Yes.
11 matches
Mail list logo
