Sylvain Beucler wrote:
> I imported module 'putenv'.
Did you also add the stdlib module?
> /usr/src/t/freedink-1.08.20081207/cross/gnulib/lib/../../../gnulib/lib/putenv.c:107:
> undefined reference to `_environ'
> /usr/src/t/freedink-1.08.20081207/cross/gnulib/lib/../../../gnulib/lib/putenv.c:1
Sam Steingold wrote:
> /home/sds/src/clisp/current/build-gxx-g/../src/time.d:75: undefined reference
> to `rpl_gettimeofday(timeval*, void*)'
> time.o: In function `C_sleep()':
> /home/sds/src/clisp/current/build-gxx-g/../src/time.d:503: undefined
> reference to `rpl_gettimeofday(timeval*, void*
Simon Josefsson wrote:
> +# gl_MANYWARN_ALL_GCC(VARIABLE)
> +# -
> +# Add all documented GCC (currently as per version 4.3.2) warning
> +# parameters to variable VARIABLE. Note that you need to test them
> +# using gl_WARN_ADD if you want to make sure your gcc understa
Bruno Haible wrote:
> Btw, how do you need to write code such that gcc uses the SSE3 instructions?
You mean auto-vectorization, as opposed to explicitly using the
mmintrin.h or __builtin_foo APIs? I think you need to specify a -march=
that names an architecture that has sse3 (or just -msse3, but
Simon Josefsson wrote:
> 3) Is there any chance that the #define gethostname rpl_gethostname and
> replacement prototype of gethostname in gnulib's unistd.h will cause
> problems? Consider that gethostname in winsock2.h is declared with
> PASCAL calling conventions, so the prototype is not the sa
Simon Josefsson wrote:
> Thanks for testing. I think the test "just happens" to fail under
> cygwin, but as long as that is always consistent, I think that is fine.
In a sense, HAVE_WINSOCK2_H=0 is in fact correct on Cygwin. Even though
the header is available it's not correct to include it in
Simon Josefsson wrote:
> continue to work under cygwin. Btw, could you quote the part from
> config.log which explains _why_ the m4 macro fails under cygwin? It
> isn't clear from the M4 check that it would fail under cygwin, but maybe
> it is just my lack of knowledge with cygwin. Still, if it
Bruno Haible wrote:
> The precise circumstances are not clear to me. When I run, from an rxvt
> running the msys /bin/sh,
>
> $ H:/msys/local/bin/msgfmt.exe --statistics /dev/null
>
> it succeeds. When from this shell, I run "cmd" (the Microsoft command
> interpreter), and from there
Like Eri
Eric Blake wrote:
> the pair 'extern inline' that causes the problem. Are we stuck with just
> telling these users that they shouldn't upgrade gcc without also upgrading
> their headers, because the old headers are broken with the new gcc?
When gcc changed the semantics they also introduced the
Eric Blake wrote:
> However, I'm not sure on mingw how to detect whether an fd is open on a
> regular file vs. a pipe. Any ideas?
Check out ser-mingw.c from gdb, they have a fair amount of MinGW pipe/fd
handling code there, e.g.
static int
fd_is_pipe (int fd)
{
if (PeekNamedPipe ((HANDLE) _ge
Bruce Korb wrote:
> I know this may be seen as flame bait, but is it not just a
> bit easier to simply presume that the gnulib library is always
> going to be at least as standards compliant as the native
> implementation? In other words, why worry? Maybe right now
> I don't use the 'a' directiv
Bruno Haible wrote:
> Volunteers wanted: If you have access to a system with
> - FreeBSD 5.x
Results for FreeBSD 5.4:
ac_cv_func_snprintf=yes
gl_cv_func_printf_directive_a=yes
gl_cv_func_printf_directive_n=yes
gl_cv_func_printf_positions=yes
gl_cv_func_printf_retval_c99=yes
gl_cv_func_printf_s
Bruno Haible wrote:
> 3) Operating system:
> - Cygwin default: __CYGWIN32__
> - Cygwin when the installer wants to use native Woe32 API (option -mwin32):
> __CYGWIN32__, _WIN32
This should be __CYGWIN__ and not __CYGWIN32__. The former is the
canonical name, the latter is
13 matches
Mail list logo
