On Mon, Jun 9, 2014 at 11:03 AM, Eli Zaretskii wrote:
> > Date: Mon, 09 Jun 2014 09:33:18 +0100
> > From: Pádraig Brady
> > Cc: bug-gnulib@gnu.org
> >
> > It's an optimized test rather than an optimization for isatty() itself.
> > Without this call the isatty() replacement is moot because the
>
Hi,
I'd like to know what would be the recommended way to deal with gnulib in a
project with mutliple shared libraries when compiled with MSVC. The context
is compilation of GNU Octave, which consists of multiple shared libraries
(one core, and several other all depending on the core one).
I can
On Fri, Feb 22, 2013 at 2:19 AM, Paul Eggert wrote:
> On 02/21/2013 08:07 PM, Michael Goffioul wrote:
>
> > _putenv will actually make a copy of the string provided
>
> Thanks, can you please try the attached patch instead?
> It uses strcmp rather than pointer compariso
On Tue, Feb 19, 2013 at 10:37 PM, John W. Eaton wrote:
> On 02/19/2013 05:46 PM, Paul Eggert wrote:
>
>> On 02/19/13 14:04, John W. Eaton wrote:
>>
>>> and also to use _putenv in the normal case when the argument string to
>>> putenv contains "VAR=VAL".
>>>
>>
>> Ouch, thanks for catching that; i
On Sun, Feb 17, 2013 at 1:59 PM, John W. Eaton wrote:
> On 02/15/2013 03:16 PM, Michael Goffioul wrote:
>
>> On Fri, Feb 15, 2013 at 2:10 PM, Paul Eggert > <mailto:egg...@cs.ucla.edu>> wrote:
>>
>> On 02/15/2013 07:10 AM, Michael Goffioul wrote:
>>
On Fri, Feb 15, 2013 at 10:24 PM, Eric Blake wrote:
> On 02/15/2013 08:10 AM, Michael Goffioul wrote:
> > The problem is that the "environ" variable is just a mirror of the
> > environment that is manipulated through GetEnvironmentVariable and
> > SetEnviro
On Fri, Feb 15, 2013 at 2:10 PM, Paul Eggert wrote:
> On 02/15/2013 07:10 AM, Michael Goffioul wrote:
> > I guess the only solution to this problem is to always _putenv and not
> manipulate "environ" directly.
>
> Thanks, is that something you can write and contribute
On Thu, Feb 14, 2013 at 4:18 PM, Paul Eggert wrote:
> On 02/14/13 10:15, Michael Goffioul wrote:
> >
> > Yes, it fixes the problem.
>
> Thanks for checking. I installed that into the gnulib master.
>
Thanks. However I made some further tests and found out that gnulib&#x
On Thu, Feb 14, 2013 at 1:34 AM, Paul Eggert wrote:
> On 02/13/2013 06:54 PM, Michael Goffioul wrote:
> > what would be the correct fix?
>
> Does the following fix things? Totally untested; I don't use MSVC.
>
> diff --git a/lib/putenv.c b/lib/putenv.c
> index 5f
On Wed, Feb 13, 2013 at 12:35 PM, Michael Goffioul <
michael.goffi...@gmail.com> wrote:
>
>
> On Tue, Feb 12, 2013 at 11:34 PM, Max Brister wrote:
>
>> On Mon, Feb 11, 2013 at 7:47 PM, Michael Goffioul
>> wrote:
>> > Hi Max,
>> >
>>
On Wed, Jan 2, 2013 at 9:48 AM, Michael Goffioul wrote:
> On Sun, Dec 23, 2012 at 3:51 PM, Michael Goffioul <
> michael.goffi...@gmail.com> wrote:
>
>> On Sun, Dec 23, 2012 at 3:25 PM, Eli Zaretskii wrote:
>>
>>> > Date: Thu, 20 Dec 2012 19:0
On Sun, Dec 23, 2012 at 3:51 PM, Michael Goffioul <
michael.goffi...@gmail.com> wrote:
> On Sun, Dec 23, 2012 at 3:25 PM, Eli Zaretskii wrote:
>
>> > Date: Thu, 20 Dec 2012 19:02:03 -0500
>> > From: Michael Goffioul
>> >
>> > We've got a
On Sun, Dec 23, 2012 at 3:25 PM, Eli Zaretskii wrote:
> > Date: Thu, 20 Dec 2012 19:02:03 -0500
> > From: Michael Goffioul
> >
> > We've got a bug report in octave [1] that seems to indicate that gnulib's
> > replacement of isatty is incorrect on
Hi,
We've got a bug report in octave [1] that seems to indicate that gnulib's
replacement of isatty is incorrect on Windows 8 (it's fine up to Windows
7). Looking at the implementation, it first calls the Windows _isatty
version, then checks the last 2 bits of the handle associated with the file
d
Hi,
I get a compilation failure in canonicalize.c due to unsupported C99
feature in MSVC, namely the ability to define variables anywhere in C code.
Is is possible to swap lines 102 and 103 in that file? That is:
91 char *
92 canonicalize_filename_mode (const char *name, canonicalize_mode_t
c
On Sun, Sep 30, 2012 at 7:24 PM, Paul Eggert wrote:
> On 09/30/2012 03:22 PM, Bruno Haible wrote:
> > Nope. MSVC does *not* support 'inline' for functions.
>
> Thanks for catching that. Sorry, I thought they
> supported it, it's been in the standard for what,
> 12 years now?
>
Unfortunately, MS
On Wed, Aug 29, 2012 at 6:31 PM, Paul Eggert wrote:
> On 08/29/2012 10:16 AM, Michael Goffioul wrote:
> \
> > My GCC stdbool.h is quite different:
> >
> > #ifndef __cplusplus
> >
> > #define bool_Bool
> > #define true1
> > #define false
On Wed, Aug 29, 2012 at 6:13 PM, Paul Eggert wrote:
> On 08/29/2012 10:00 AM, John W. Eaton wrote:
> > Why define true, false, and bool to anything when using C++?
>
> Maybe it's for '#ifdef bool' but to be honest I'm just doing what
> GCC does. Perhaps you can ask the GCC developers why they do
On Wed, Aug 29, 2012 at 4:44 PM, Michael Goffioul <
michael.goffi...@gmail.com> wrote:
> Thanks, that should indeed redefining true and false...
>
I meant: that should indeed avoid redefining true and false...
Michael.
:00:00 2001
> From: Paul Eggert
> Date: Wed, 29 Aug 2012 07:52:32 -0700
> Subject: [PATCH] stdbool: be more compatible with mixed C/C++ compiles
>
> * lib/stdbool.in.h (_Bool, true, false) [__cplusplus]:
> Define to bool, true, false, respectively, as GCC's builtin
> st
Hi,
When compiling octave with MSVC under Windows, I found an issue with how
stdbool.h (from gnulib) redefines true/false unconditionally, even in C++
mode. The net result is that in C++, true/false do not have the bool type
anymore, but integer. This creates miscompilation in octave code, where t
On Fri, Jul 20, 2012 at 2:17 PM, Дилян Палаузов
wrote:
> Hello Michael,
>
> there is a point with dllexport/dllimport, however when not building for
> Windows, the argumentation does not apply and the recommendation for use
> LIBFOO_DLL_EXPORTED in the header files is suboptimal in my eyes.
>
Ind
On Fri, Jul 20, 2012 at 12:56 PM, Дилян Палаузов
wrote:
> Defining LIBFOO_DLL_EXPORTED in public header files has no added value
> from the user's perspective: mentioning a function in the public header
> files implies, that the function is visible. As suggested, there is
> another way to achieve
Hi,
While compiling octave under MSVC with current gnulib, I got the following
problems (leading undefined references at link stage):
1) dirchownmod uses fchown, but this is not available on Windows and
there's no replacement in gnulib
2) savewd uses waitpid, but it doesn't have a dependency on g
On Thu, May 31, 2012 at 8:08 PM, Jim Meyering wrote:
> Michael Goffioul wrote:
> > While trying to compile current octave source with MSVC, I got an error
> at the
> > compilation of savewd.c, because of missing sys/wait.h header. Indeed
> that
> > header is include
Hi,
While trying to compile current octave source with MSVC, I got an error at
the compilation of savewd.c, because of missing sys/wait.h header. Indeed
that header is included directly by savewd.c, but the savewd module does
not depend on sys_wait. So the gnulib replacement for sys/wait.h is not
On Sun, Mar 11, 2012 at 11:50 PM, Michael Goffioul
wrote:
> On Sun, Mar 11, 2012 at 10:52 PM, Bruno Haible wrote:
>> Michael Goffioul wrote:
>>> frexpf is actually defined as a macro in C,
>>> and as an inline function in C++.
>>
>> Normally gnulib avo
On Wed, Mar 14, 2012 at 4:42 PM, Bastien ROUCARIES
wrote:
> On Wed, Mar 14, 2012 at 11:22 AM, Michael Goffioul
> wrote:
>> On Wed, Mar 14, 2012 at 9:48 AM, Bruno Haible wrote:
>>> Michael Goffioul wrote:
>>>> I encountered a compilation error with MSVC when
On Wed, Mar 14, 2012 at 9:48 AM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> I encountered a compilation error with MSVC when compiling floor.c in
>> strict floating-point mode (-fp:strict).
>
> Note that the use of -fp:strict also leads to test failures such as
On Sun, Mar 11, 2012 at 10:52 PM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> frexpf is actually defined as a macro in C,
>> and as an inline function in C++.
>
> Normally gnulib avoids collisions with system functions by checking whether
> a system function exists,
On Sun, Mar 11, 2012 at 6:58 PM, Michael Goffioul
wrote:
> To confirm my suspicion, I tested the following sample:
>
> #include "config.h"
> #include
> #include
>
> int main (int argc, char** argv)
> {
> volatile float x;
> float
On Sun, Mar 11, 2012 at 6:30 PM, Michael Goffioul
wrote:
> Hi,
>
> I'm trying to clarify a potential issue when using gnulib float math
> functions like frexpf (and possibly others) with MSVC9. It all started
> when compiling octave and getting link error because of dupl
Hi,
I'm trying to clarify a potential issue when using gnulib float math
functions like frexpf (and possibly others) with MSVC9. It all started
when compiling octave and getting link error because of duplicate
symbols like frexpf in libgnulib.la and octave code like Cell.cc. I
don't fully unsersta
On Sun, Mar 11, 2012 at 4:16 PM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> Same problem occurs in cbrt.c and cbrtf.c.
>
> ... and probably some others of newly added math function source files.
> This is an area with work in progress. Can you remind me about this issue
&g
On Tue, Feb 28, 2012 at 10:52 AM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> With the #pragma statement, the compilation error disappears, thanks.
>
> Thanks for verifying that we were on the right track.
>
>> I think the same
>> problem will appear in round
On Thu, Feb 23, 2012 at 10:12 AM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> I encountered a compilation error with MSVC when compiling floor.c in
>> strict floating-point mode (-fp:strict). The error is:
>>
>> "error C2099: initializer is not a constant"
Hi,
While trying to compile octave-3.6.1 with MSVC, I found a problem
related to the ordering of include paths in CPPFLAGS. For instance, in
liboctave/Makefile.am, the flags are defined as:
AM_CPPFLAGS = \
@CPPFLAGS@ -I../libgnu -I$(top_srcdir)/libgnu \
-I$(top_srcdir)/libcruft/misc
So if yo
Hi,
I encountered a compilation error with MSVC when compiling floor.c in
strict floating-point mode (-fp:strict). The error is:
"error C2099: initializer is not a constant"
The error is triggered by the initializer for the constant variable
TWO_MANT_DIG and is documented here:
http://msdn.micr
Hi,
In the context of octave, I need to have a loop that sleeps for about
100ms then perform some action. Most of the time, the action to
perform is empty so the loop is mainly sleeping. I don't expect such
loop to be CPU-consuming. To build this loop in octave, I'm using
octave_usleep, which call
Hi,
With a current version of gnulib and MSVC10, I get a compilation error
in octave due to signbit being #define'd by gnulib's math.h module.
The configure script ends up with GNULIB_SIGNBIT being 1 and
REPLACE_SIGNBIT being 1. This causes signbit being #define'd as
# define signbit(x) \
(si
Hi,
When trying to compile current octave with MSVC10, I get a bunch of
macro redefinition in errno.h module. See the following from the
involved headers:
$ grep ECONNRESET errno.h
# define ECONNRESET 10054
$ grep ECONNRESET /c/Program\ Files/Microsoft\ Visual\ Studio\
10.0/VC/include/errn
On Mon, Sep 12, 2011 at 12:17 AM, Bruno Haible wrote:
> This alone is not terribly useful. Currently while building the POSIX
> emulation modules of gnulib I'm encountering ca. 60 compilation errors.
> And this is only the compilation errors; the test failures will come
> after that.
>
> If you wa
On Sun, Sep 11, 2011 at 10:23 PM, Bastien ROUCARIES
wrote:
>> - rename m4 test produced filesystem corruption that lead to full recheck on
>> the next reboot; I had to disable the test completely
>
> Funny :) Do you know why this test does not do this on mingw ?
No. To be honest, I didn't investi
On Sun, Sep 11, 2011 at 8:59 PM, Bruno Haible wrote:
> In a current situation, a number of gnulib modules compile flawlessly
> on MSVC 9. Therefore it's time to document its current status.
>
> Further fixes for this platform are, of course, welcome.
BTW, you might also have a second reading of t
On Sun, Sep 11, 2011 at 8:59 PM, Bruno Haible wrote:
> In a current situation, a number of gnulib modules compile flawlessly
> on MSVC 9. Therefore it's time to document its current status.
>
> Further fixes for this platform are, of course, welcome.
For quite some time now, I've been tweaking my
On Sun, Sep 11, 2011 at 8:24 PM, Bruno Haible wrote:
>> The MSVC compiler also has no .
>
> And it has no strcasecmp(), strncasecmp() functions. To fix this, it's
> sufficient to de-obsololetize the 'strcase' module, which provides the
> replacements.
You probably made my day ;)
This will probabl
Hi,
I'd like to propose the 2 following patches that add support for backslashes in
path names for the corresponding macros. This allows those macros to play
nicer in Win32 environment.
Michael.
absolute-header.m4.diff
Description: Binary data
include_next.m4.diff
Description: Binary data
On Fri, Sep 2, 2011 at 11:26 PM, Peter Rosin wrote:
> The web has a couple of different forked versions of cccl. What is
> the "upstream" for that script? There is ancient support for some
> version of cccl in libtool, but I didn't get it to work with any
> version of cccl that I found (some thing
On Fri, Sep 2, 2011 at 10:38 PM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> > Indeed. The problem is that after the 2011-08-05 commit, m4/chdir-long.m4
>> > and lib/chdir-long are no longer in sync: The .m4 file assumes that only
>> > and will be included
On Fri, Aug 26, 2011 at 10:08 PM, Bruno Haible wrote:
> Eric Blake wrote:
>> > Just for the record, it turns out the chdir-long is not compiled, because
>> > the variable $gl_cv_have_arbitrary_file_name_length_limit ends up being
>> "no".
>>
>> Aha - that's a bug in the chdir-long module.
>
> Inde
On Sun, Aug 28, 2011 at 7:30 AM, Bruno Haible wrote:
> Hi Michael,
>
>> It appears the problem comes from the fact that stdio.h is pulled in
>> indirectly from
>> config.h, hence it is not surrounded by the __need_FILE macro that should
>> prevent
>> the problem from occuring. The inclusion patt
stdint.h implementation I'm using, see [1])
stdio.h (because of wchar.h implementation in gnulib)
I assume the same problem will occur in "open" module.
Michael.
[1] http://msinttypes.googlecode.com/svn/trunk/stdint.h
On Sun, Aug 28, 2011 at 12:01 AM, Michael Goffioul
wrote:
Hi,
When compiling octave with MSVC, I found an infinite recursion problem
with fopen. As fopen.c is compiled in C mode and GNULIB_FOPEN and
REPLACE_FOPEN are both 1 on my setup, it is compiled with
"fopen" being redefined as "rpl_open". This means that orig_fopen will
end up calling rpl_fopen (an
On Fri, Aug 26, 2011 at 10:13 PM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> Windows+MSVC. I know this is not a gnulib target.
>
> Yes. But it could become a gnulib target if the $CC wrapper script was agreed
> upon in GNU. For example, if Automake would distribute it, l
On Fri, Aug 26, 2011 at 8:43 PM, Michael Goffioul
wrote:
> On Fri, Aug 26, 2011 at 5:13 PM, John W. Eaton wrote:
>> It seems to be working for me with a Debian system.
>>
>> Is chdir-long.lo listed in the gl_LTLIBOBJS variable in the generated
>> libgnu/Makefile on you
On Fri, Aug 26, 2011 at 5:13 PM, John W. Eaton wrote:
> It seems to be working for me with a Debian system.
>
> Is chdir-long.lo listed in the gl_LTLIBOBJS variable in the generated
> libgnu/Makefile on your system?
No.
> Do you have the most recent gnulib sources?
Cloned about 2 days ago, from
On Fri, Aug 26, 2011 at 1:44 PM, Bruno Haible wrote:
> Hi,
>
> Michael Goffioul wrote:
>> While compiling Octave, I got undefined references within the gnulib
>> module.
>> Namely:
>> - chdir_long undefined, referenced in save-cwd.c
>
> This is very aston
Hi,
While compiling Octave, I got undefined references within the gnulib module.
Namely:
- chdir_long undefined, referenced in save-cwd.c
- strncasecmp undefined, referenced in strptime.c
After running the bootstrap script, I can see that the corresponding
source files
are taken into account (cop
On Sun, May 2, 2010 at 8:27 PM, Bruno Haible wrote:
> Hi,
>
> Michael Goffioul wrote:
>> When trying to compile gnulib (from octave), it fails at compiling
>> mbsinit.c. It seems this is due to the fact that on my system (MSVC)
>> mbsinit is declared inlined in wchar.h.
When trying to compile gnulib (from octave), it fails at compiling
mbsinit.c. It seems this is due to the fact that on my system (MSVC)
mbsinit is declared inlined in wchar.h. The configure script fails to
detect the system mbsinit, because of link error, and the compiler
fails to compile the repla
On Tue, Feb 23, 2010 at 7:15 AM, Michael Goffioul
wrote:
> Thanks. I tried the patch and gettimeofday is not compiled in. However,
Sorry, I meant "is *now* compiled in".
Michael.
On Mon, Feb 22, 2010 at 4:05 PM, Eric Blake wrote:
> According to Michael Goffioul on 2/21/2010 4:09 PM:
>> I think that because of the outer "if test $ac_cv_func_gettimeofday =
>> yes; then",
>> REPLACE_GETTIMEOFDAY can only be set to 1 on systems that already
>
Hi,
I'm trying to compile octave (which uses gnulib) with MSVC, but got
a problem related to a recent change introduced in the gnulib source
tree, namely
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=de4d0a383be20eb6cbeb09ecbd66a5514779b914
I think that because of the outer "if
63 matches
Mail list logo
