Re: safer way to use gnulib

[Jaroslav Hajek]

2010/3/15 John W. Eaton <address@hidden>:
> 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
>

Brilliant. Unless this causes problems in the immediate future, I
suppose we can make a new snapshot?


-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz