First, thanks for working on the new --automake-subdir feature. We've
been wanting to use a non-recursive build of gnulib with Octave for many
years but have never been able to make it work completely with the
previous non-recursive-gnulib-prefix-hack module.
For the following, I updated to
On 05/06/2018 10:33 AM, Jim Meyering wrote:
Here's the relevant section: (from
https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html)
Whenever possible, please stick to the active voice, avoiding the
passive, and use the present tense, not the future teste. For
instance, write “The funct
Is there anything I can do to help get this change accepted as part of
gnulib?
I'd really like to be able to use a completely non-recursive Makefile
for Octave.
jwe
On 11/28/2016 12:40 AM, John W. Eaton wrote:
On 11/27/2016 06:18 PM, Bruno Haible wrote:
John,
I
The test in link.m4 needs to include to provide a declaration
for the rename function. The test fails if building with GCC's
-Werror=implicit-function-declaration option.
This was reported as part of a bug with building Octave on Fedora, which
now uses -Werror=implicit-function-declaration b
On 11/27/2016 06:18 PM, Bruno Haible wrote:
John,
I added
AC_CONFIG_LIBOBJ_DIR([libgnu])
to my configure.ac file. Maybe gnulib-tool could do this automatically
if --non-recursive-makefile is specified?
gnulib-tool does not rely on AC_LIBOBJ and friends, because these autoconf
macros ass
On 11/27/2016 05:02 PM, Bruno Haible wrote:
* I would add a check to make sure that --non-recursive-makefile is
only used together with the --makefile-name option. I cannot see how/why
someone would use --non-recursive-makefile without --makefile-name.
This simplies some of the logic (e.g.
On 11/27/2016 04:29 PM, Bruno Haible wrote:
When you specify --makefile-name=module.mk, gnulib-tool knows that you
don't want a top-level Makefile.am and does not generate AUTOMAKE_OPTIONS
and generates augmentations (+=) of the other variables instead of assignments.
OK, I didn't realize that
On 11/27/2016 07:52 AM, John W. Eaton wrote:
On 10/22/2016 03:04 PM, Bruno Haible wrote:
The idea would be to have gnulib-tool emit the correct code for the
{Bison,coreutils,Octave} case right away, triggered by some command line
option.
If you want to help us here, please use the *current
On 06/24/2016 11:01 PM, Tatsuro MATSUOKA wrote:
- Original Message -
From: John W. Eaton
To: gnulib
Cc: j...@octave.org
Date: 2016/6/25, Sat 04:46
Subject: gethostname on 64-bit Windows
I needed the attached change to cross compile Octave for i686-w64-mingw32.
Without it
I needed the attached change to cross compile Octave for i686-w64-mingw32.
Without it, rpl_gethostname was undefined because w64 has a gethostname
function so gethostname.c is not added to the list of files to build but
gethostname was still being redefined to rpl_gethostname.
jwe
diff -uNr
The bootstrap script has
# Extra files from gnulib, which override files from other sources.
test -z "${gnulib_extra_files}" && \
gnulib_extra_files="
build-aux/install-sh
build-aux/mdate-sh
build-aux/texinfo.tex
build-aux/depcomp
build-aux/config.guess
On 08/31/2015 09:54 AM, Paul Eggert wrote:
Juan Pablo Carbajal wrote:
Is this a bug in gnulib?
Do you have file systems where '/' does not work to separate file name
components? Like VMS or something? If so, it's a problem, though I'm
not sure it's a bug, as most of gnulib doesn't claim to p
I'm getting an error about rpl_gethostname undefined when compiling
Octave for MinGW. HAVE_GETHOSTNAME is 1, so the AC_LIBOBJ macro from
the module/gethostname file is not used, but unistd.in.h is checking
GNULIB_GETHOSTNAME, which is also defined to 1. So the macros there are
expanded and I
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; it suggests further
fixes. Could you please try this patch to gnul
On 02/18/2013 10:40 PM, Paul Eggert wrote:
Thanks, how about this change instead?
It's a bit more conservative about always using
_putenv and setting errno. And it uses
WIN32_LEAN_AND_MEAN.
I need the attached additional changes to provide declarations for
putenv_result and putenv_error in th
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:
> I guess the only solution to this problem is to always _putenv
and not manipulate "environ" directly.
After updating gnulib in the Octave sources, I started seeing the
following error:
In file included from /usr/include/c++/4.7/cstdlib:66:0,
from /usr/include/c++/4.7/bits/stl_algo.h:61,
from /usr/include/c++/4.7/algorithm:63,
from /home/jw
On 01/16/2013 06:49 PM, Paul Eggert wrote:
Thanks, I pushed this:
Thanks for the quick response. Do you expect this to continue to work
for older versions of mingw? I don't care about that myself, I'm just
wondering whether that is something gnulib should do. Or is the target
for gnulib l
While trying to build Octave for mingw, I hit the following error:
../../liboctave/system/oct-env.cc: In member function 'std::string
octave_env::do_get_host_name() const':
../../liboctave/system/oct-env.cc:455:20: error: 'gethostname' is not a
member of 'gnulib'
../../liboctave/system/oct
On 29-Aug-2012, Bastien ROUCARIES wrote:
| n Wed, Aug 29, 2012 at 7:36 PM, John W. Eaton wrote:
| > On 29-Aug-2012, 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++?
| > |
| > | M
On 29-Aug-2012, 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 wh
On 29-Aug-2012, John W. Eaton wrote:
| Michael, how is stdbool.h being included in Octave C++ sources? Maybe
| that's a mistake that should be fixed.
Oh, I see it ends up being included in data.cc because we include
base64.h from gnulib there.
jwe
On 29-Aug-2012, Michael Goffioul wrote:
| On Wed, Aug 29, 2012 at 4:44 PM, Michael Goffioul
| wrote:
|
| Thanks, that should indeed redefining true and false...
|
|
| I meant: that should indeed avoid redefining true and false...
Why define true, false, and bool to anything when using C++
On 7-Jun-2012, Paul Eggert wrote:
| Much of gnulib has never been ported to MSVC / MingW
| and apparently octave is using that part. I suggest
| using Cygwin.
If it were up to me, I'd go a step further and say, "don't use
Windows," but the reality is that that's not going to fly with many of
Oc
On 23-Feb-2012, Paul Eggert wrote:
| On 02/23/2012 02:08 AM, Michael Goffioul wrote:
| > 2) in liboctave/Makefile.am, @CPPFLAGS@ should be moved to the end, or
| > after "-I../libgnu"
|
| That's what I'd do.
Seems reasonable to me. I'm not sure why I put @CPPFLAGS@ first.
I'll make this change.
Follow-up Comment #5, bug #35580 (project octave):
OK.
You aren't running autogen.sh for a released version of Octave, are you? It
is not needed except to build sources from the mercurial archive. If you have
a tarball release, you just need to use the included configure script.
__
Follow-up Comment #3, bug #35580 (project octave):
The error is also coming from the bootstrap script, which we should be using
unmodified from gnulib. So the right place to fix this is in gnulib so that
all projects using gnulib will get the fix, not just Octave.
___
On 29-Nov-2011, Eric Blake wrote:
| On 11/29/2011 01:01 AM, John W. Eaton wrote:
| > While trying to cross compile Octave for MinGW, I hit the following
| > errors:
| >
| > In file included from /home/jwe/src/octave/liboctave/oct-time.h:26:0,
| >from /home
While trying to cross compile Octave for MinGW, I hit the following
errors:
In file included from /home/jwe/src/octave/liboctave/oct-time.h:26:0,
from /home/jwe/src/octave/liboctave/file-stat.h:28,
from /home/jwe/src/octave/liboctave/file-ops.cc:43:
/usr/i
On 26-Aug-2011, Michael Goffioul wrote:
| 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
| >
| >
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 c
On 9-Aug-2011, Eric Blake wrote:
| I'm thinking this may be a bug in gnulib. I also know that glibc 2.14
| fixed one fclose() bug in how fclose() relates to fflush(), but at the
| expense of introducing another, and that gnulib does not yet detect and
| work around that glibc bug. I'm assumi
I discovered the following surprising behavior recently when adding a
few more gnulib:: namespace tags to the Octave sources. Eventually I
was able to generate the relatively small example attached below that
shows the same behavior and is independent of Octave.
The problem seems to be that fseek
On 3-Jul-2011, Bruno Haible wrote:
| subdirectory modules/fortran/ -, and that you follow the GNU conventions for
| Fortran code (whatever these may be - you can find out by looking at octave
| in octave-3.4.2/libcruft/ [3]).
I wouldn't recommend trying to follow the style of the Fortran code in
On 20-Jul-2011, Bastien ROUCARIES wrote:
| I agree libcraft is really ugly.
|
| Could you review the binding ?
I don't use Fortran much these days. I don't write anything new using
it, so I'm probably not the right person to review it.
| Do you have use in octave?
Not really. The Fortran cod
On 21-Apr-2011, Bruno Haible wrote:
| Hi John,
|
| John W. Eaton wrote:
| > When I execute
| >
| > git clone --depth=2 git://git.sv.gnu.org/gnulib
| >
| > as is done when running the bootstrap script for the first time, the
| > git process hangs.
|
| Yes, for me too it h
When I execute
git clone --depth=2 git://git.sv.gnu.org/gnulib
as is done when running the bootstrap script for the first time, the
git process hangs. Several people have reported this problem when
building Octave from a Mercurial checkout, which does not start out
with a gnulib subdirectory b
When I execute
git clone --depth=2 git://git.sv.gnu.org/gnulib
as is done when running the bootstrap script for the first time, the
git process hangs. Several people have reported this problem when
building Octave from a Mercurial checkout, which does not start out
with a gnulib subdirectory b
On 10-Feb-2011, Jim Meyering wrote:
| FYI, another "user":
You could also add Octave to that list with the URL
http://hg.savannah.gnu.org/hgweb/octave.
Thanks,
jwe
On 27-Jan-2011, Benjamin Lindner wrote:
| So currently, it would require unistd.h to be either included twice,
| or be included before winsock2.h to work properly.
I think it would be OK if we had to include unistd.h before
winsock2.h. However, I did not know that was a requirement. If it is
th
On 14-Jan-2011, Jim Meyering wrote:
| John W. Eaton wrote:
|
| > I updated Octave's copy of the bootstrap script from gnulib's version
| > today and hit an error because gnulib_path was set to ''. The code in
| > the bootstrap script for this is
| >
| > git_
I updated Octave's copy of the bootstrap script from gnulib's version
today and hit an error because gnulib_path was set to ''. The code in
the bootstrap script for this is
git_modules_config () {
test -f .gitmodules && git config --file .gitmodules "$@"
}
gnulib_path=`git_modules_conf
Hi,
I'd like to use the filemode module in a C++ file but found that it
does not have extern "C" magic. I started to submit a patch, but
stopped when I saw that filemode.h has
# if HAVE_DECL_STRMODE
# include /* FreeBSD, OpenBSD */
# include /* NetBSD */
# else
void strmode (mode_t
On 10-Jan-2011, Bruno Haible wrote:
| These are simply the old replacement idioms that are not C++ safe.
| We introduced the C++ safe idioms for most header files in March 2010,
| but the old idioms are still used in a couple of places:
|
| m4/eaccess.m4:[AC_DEFINE([eaccess], [access],
| m4/f
I received a bug report for Octave that was the result of fnmatch
being defined to posix_fnmatch in config.h. I think this is due to
AC_DEFINE_UNQUOTED([fnmatch], [${gl_fnmatch_required_lowercase}_fnmatch],
[Define to a replacement function name for fnmatch().])
in gnulib's fnmatch.m4
On 1-Jan-2011, Karl Berry wrote:
| Subject: Re: [PATCH 1/2] maint: new rule to update copyright year ranges
|
| This brings up a related topic that belatedly crossed my mind recently.
| rms stated an extra requirement of making a statement in the README
| about copyright ranges when they are
On 28-Apr-2010, Bruno Haible wrote:
| The way to do that is that you provide a good implementation of said
| functions opendir, readdir, and closedir.
Sure, I understand that. Sorry if my earlier message sounded like I
was expecting someone else to do this part.
| Projects that use gnulib have
On 9-Apr-2010, Paolo Bonzini wrote:
| On 04/09/2010 11:04 AM, Bruno Haible wrote:
| > Indeed. But since mingw has it but MSVC doesn't, this raises the
| > question: how important is the MSVC porting platform (use Microsoft's
| > compiler and include files [proprietary but downloadable at zero cos
On 9-Apr-2010, Jim Meyering wrote:
| Paolo Bonzini wrote:
| > On 04/09/2010 12:48 PM, Jim Meyering wrote:
| >> Of course, if you have some precise -- and useful enough to count as a
| >> reasonable porting target -- development environment in mind for which
| >> this particular replacement is req
The current gnulib unistd.in.h file includes the following section:
#if @GNULIB_GETHOSTNAME@
/* Get all possible declarations of gethostname(). */
# if @UNISTD_H_HAVE_WINSOCK2_H@
# if !defined _GL_SYS_SOCKET_H
# undef socket
# define socket socket_used_without_inclu
An additional problem showed up on OS X systems:
libtool: compile: g++-4.2 -DHAVE_CONFIG_H -I. -I.. -I/sw/lib/flex/include
-I/sw/include -O0 -g -m32 -I/sw/include/freetype2 -I/sw/include/qhull
-I/usr/include -I../libgnu -I../libgnu -I../libcruft/misc -I../liboctave
-I../liboctave -I. -I. -I/
On 13-Mar-2010, Bruno Haible wrote:
| Good point. I'm adding this as an extra check in the testsuite:
Thanks for the additional changes. I modified the Octave sources so
that GNULIB_NAMESPACE is defined to gnulib and tagged all the uses
that were reported by GCC warnings. Everything worked fine
On 6-Mar-2010, Bruno Haible wrote:
| John W. Eaton wrote:
| > How can one easily find all the places where the GNULIB_NAMESPACE tag
| > is needed? Is there some way we can get the compiler to help with
| > this job?
|
| Good point. I'm adding a macro _GL_CXXALIASWARN, so that
Is there any reason not to commit the changes for the new c++defs
module?
Earlier, I wrote:
| How can one easily find all the places where the GNULIB_NAMESPACE tag
| is needed? Is there some way we can get the compiler to help with
| this job?
|
| The reason I liked the idea of having the gnuli
On 23-Feb-2010, Eric Blake wrote:
| According to John W. Eaton on 2/23/2010 7:51 AM:
| > The only other error I'm seeing is
| >
| > libtool: compile: g++ -DHAVE_CONFIG_H -I.
-I/home/jwe/src/octave/liboctave -I.. -I../libgnu -I/home/jwe/src/octave/libgnu
-I/home/jwe/src/octave
On 23-Feb-2010, Bruno Haible wrote:
| John W. Eaton wrote:
|
| > The next problem I encountered was
| >
| > libtool: compile: g++ -DHAVE_CONFIG_H -I.
-I/home/jwe/src/octave/liboctave -I.. -I../libgnu -I/home/jwe/src/octave/libgnu
-I/home/jwe/src/octave/libcruft/misc -ggdb3 -DHAVE
On 23-Feb-2010, Bruno Haible wrote:
| John W. Eaton wrote:
| > ../libgnu/stdio.h:1087: error: previous declaration of 'int
_gl_cxxalias_dummy' with 'C++' linkage
| > ../libgnu/signal.h:246: error: conflicts with new declaration with 'C'
linkage
|
| Thank
On 22-Feb-2010, Bruno Haible wrote:
| Here come the proposed changes to allow C++ developers to choose among
| the default mode with many
| #define func rpl_func
| macro definitions and a "namespace mode", which is more in line with the
| way C++ programs are built.
|
| I handled all header fil
On 20-Feb-2010, Bruno Haible wrote:
| And when I change the first line to
|
| namespace system {
| #include
| }
| using namespace system;
|
| then there is a different error message:
|
| $ g++ -S foo.cc
| foo.cc: In function ‘int bar_uses_gnulib_implicitly()’:
| foo.cc:37: error: reference to
On 19-Feb-2010, I wrote:
| To handle all the cases, I find that I need to write
|
| #ifdef __cplusplus
| namespace gnulib
| {
| int (*const open) (const char *filename, int flags, ...) =
| # if @GNULIB_OPEN@
| # if @REPLACE_OPEN@
| ::rpl_open;
| # else
| ::open;
|
On 18-Feb-2010, Bruno Haible wrote:
| Ralf proposes:
| > I suggest you could
| > produce a helper header to #undef them again; you could even do that
| > automatically during bootstrap with above. Then only a portability
| > layer would need to avoid using these symbols in another namespace.
|
|
On 18-Feb-2010, Ralf Wildenhues wrote:
| * John W. Eaton wrote on Thu, Feb 18, 2010 at 09:22:39PM CET:
| > On 18-Feb-2010, Ralf Wildenhues wrote:
| > | $ autoconf '--trace=AC_DEFINE:$1:$2' | grep ':rpl_[^:]*$'
| >
| > Running this with the Octave
On 18-Feb-2010, Ralf Wildenhues wrote:
| Hello John,
|
| * John W. Eaton wrote on Thu, Feb 18, 2010 at 08:37:30PM CET:
| > However, there is one issue that has caused a bit of trouble as I
| > have started using more gnulib modules.
| >
| > Octave is mostly written in C++ and am
Hi,
I'm trying to use gnulib with GNU Octave and am overall very pleased,
as it is allowing me to remove a lot of cruft from Octave's source
files and just assume that a POSIX environment is available without
having to use a lot of #ifdefs. To me, that's a significant
improvement.
However, there
On 7-Feb-2010, Bruno Haible wrote:
| John W. Eaton wrote:
| > and I've received reports about the following undefined references
| > when linking:
| >
| > .libs/liboctave_la-lo-cutils.o:lo-cutils.c:(.text+0x4f): undefi
I have the following modules listed in the bootstrap.conf file for
Octave:
# gnulib modules used by this package.
gnulib_modules="
c-strcase crypto/md5fcntl fnmatch getcwdgethostname
getopt-gnu gettimeofday glob link lstat mkdir
mkfifo s
On 9-Jan-2010, Bruno Haible wrote:
| Hi John,
|
| John W. Eaton wrote:
| > Looking at lib/glob.c in the gnulib sources, there is some
| > Windows-specific code, so it looks like it is intended to work on
| > Windows systems
|
| > Is glob.c expected to work on Windows systems?
|
|
the attached patch.
Thanks,
jwe
>From 1641dbca79baee5b57a3bc691f2050d3da6dd135 Mon Sep 17 00:00:00 2001
From: John W. Eaton
Date: Thu, 7 Jan 2010 13:08:33 -0500
Subject: [PATCH] glob.in.h: define __BEGIN_DECLS and __END_DECLS for C++
---
ChangeLog |5 +
lib/glob.in.h |
#include statement in the Octave sources with extern "C".
jwe
>From 9c5eb4db02eaae3b8d2dc65a2a2c7e42b8aa8694 Mon Sep 17 00:00:00 2001
From: John W. Eaton
Date: Thu, 7 Jan 2010 02:03:16 -0500
Subject: [PATCH] wctype.in.h: add extern "C" block for C++
---
ChangeLog
Looking at lib/glob.c in the gnulib sources, there is some
Windows-specific code, so it looks like it is intended to work on
Windows systems, but there are some things that don't look quite
right. For example, it does not seem to uniformly use backslash as a
directory separator, and if WINDOWS32 i
I'm using the glob module in GNU Octave and a Windows user complained
that linking failed with an undefined reference to getlogin.
The problem appears to be that getlogin_r is called from glob, and the
gnulib replacement for getlogin_r calls getlogin unconditionally, but
getlogin doesn't exist on
Although lib/mkdir.c includes xalloc.h, the mkdir module doesn't
depend on xalloc. Should it? If so, how about the following change?
Thanks,
jwe
>From 78ed1c4cd10f5ef982ab09a2f19d31a786bf4cbe Mon Sep 17 00:00:00 2001
From: John W. Eaton
Date: Tue, 5 Jan 2010 03:50:42 -0500
Subject
On 14-Nov-2009, Jim Meyering wrote:
| John W. Eaton wrote:
| > Would the following patch be OK for recognizing Mercurial in the
| > build-aux/bootstrap script? It seems to work for me. Maybe there is
| > a better way of recognizing that a file is tracked, but I'm not sure
On 14-Nov-2009, Jim Meyering wrote:
| John W. Eaton wrote:
| > Is there any reason that the strftime.h header in gnulib does not use
| > extern "C"? If not, then would the following patch be OK?
|
| No one asked for it.
| I've pushed this:
Thanks!
jwe
n FILE does not exist.
jwe
commit 17efaa64f21d1834ab75904bc423a77b098c670d
Author: John W. Eaton
Date: Sat Nov 14 02:26:15 2009 -0500
build-aux/bootstrap: Recognize Mercurial for version control.
diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index 8ac13b2..799ad68 100755
Is there any reason that the strftime.h header in gnulib does not use
extern "C"? If not, then would the following patch be OK?
Thanks,
jwe
commit bf7fb16a0253f59bb1ec31e61bc92b1574e78633
Author: John W. Eaton
Date: Sat Nov 14 00:02:23 2009 -0500
strftime.h: wrap funtion decl
76 matches
Mail list logo
