Re: safer way to use gnulib

[John W. Eaton]

On 20-Feb-2010, Jaroslav Hajek wrote:

| On Sat, Feb 20, 2010 at 8:49 PM, John W. Eaton <address@hidden> wrote:
| > On 20-Feb-2010, John W. Eaton wrote:
| >
| > | On 20-Feb-2010, Jaroslav Hajek wrote:
| > |
| > | | What do you think? It seems that in the current state of affairs
| > | | gnulib actually makes Octave less portable than before.
| > |
| > | Please see the following thread on the gnulib mailing list:
| > |
| > |   http://lists.gnu.org/archive/html/bug-gnulib/2010-02/msg00113.html
| > |
| > | The last method proposed in that thread would allow us to use gnulib
| > | without having to modify Octave, and it would avoid the problems we
| > | have with the rpl_ definitions.
| >
| > Looking at the thread in the archive, I realize that it may be a bit
| > confusing to know precisely which messages I'm talking about here.
| > The "last method proposed" is here:
| >
| >  http://lists.gnu.org/archive/html/bug-gnulib/2010-02/msg00142.html
| >
| > and Bruno Haible's response is here:
| >
| >  http://lists.gnu.org/archive/html/bug-gnulib/2010-02/msg00143.html
| >
| > jwe
| >
| 
| It looks good. I don't think why enclosing #include inside namespace
| should not work. #include directives are handled by the preprocessor.
| The only problem might be with other #defines used by the system
| library, but we can hardly do anything about that.

Bruno Haible has checked in his c++defs module to the gnulib archive
and I checked in the following change to make Octave use the new
scheme of referencing gnulib replacement functions in C++ as
gnulib::FCN.

  http://hg.savannah.gnu.org/hgweb/octave/rev/479cc8a0a846

These changes should avoid the problems with gnulib defining rpl_*
functions.  If you had trouble with these definitions in the past,
please try updating (including your gnulib sources), removing your
local fixes for the problems, and rebuilding.

Bruno's changes did not go as far as putting the system headers inside
a namespace, so we do have to prefix all replacement functions with
the namespace tag.  But we also get some help if we are using GCC.
Calls to functions that might be replaced generate warnings of the
form

  lex.cc:3659: warning: call to 'fprintf' declared with attribute warning: The 
symbol ::fprintf refers to the system function. Use gnulib::fprintf instead.

Since these warnings for lex.cc and oct-parse.cc occur in generated
code that (I think) does not have problems with the redefinitions, I
chose to avoid the warnings there by undefining GNULIB_NAMESPACE after
config.h is included.

Please let me know if you see any further problems related to the
gnulib symbol definitions.

jwe