Re: rpl_canonicalize_file_name blues (while building octave)

[Jaroslav Hajek]

On Tue, Feb 2, 2010 at 11:47 PM, John W. Eaton <address@hidden> wrote:
> On  2-Feb-2010, Thorsten Meyer wrote:
>
> | I am trying to build octave from the mercurial sources on a red hat 4 
> machine
> | with all the needed gnu tools and libraries compiled manually (I have no 
> root
> | access...). So probably not everything is set up as it should be.
> |
> | Anyway, till a couple of days ago, I could build octave cleanly (last 
> successful
> | build was with 4d433bd2d4dc).
> |
> | But now with the sources freshly updated from mercurial and the gnulib 
> sources
> | also updated, the test suite fails,
> | because the function canonicalize_file_name needed by fntests.m does no 
> longer
> | exist.
> |
> | greping the sources I find that in libgnu/stdlib.h this definition is 
> active now:
> | #if 1
> | # if 1
> | #  define canonicalize_file_name rpl_canonicalize_file_name
> |
> | and syscalls.df contains this:
> | syscalls.df: XDEFUN_INTERNAL (rpl_canonicalize_file_name, args, , "-*- 
> texinfo
> | address@hidden {Built-in Function} address@hidden, @var{status}, @var{msg}]}
> | canonicalize_file_name (@var{name})\nReturn the canonical name of file
> | @address@hidden deftypefn")
> |
> | Also, the octave function canonicalize_file_name is not really gone: it has 
> been
> | renamed to rpl_canonicalize_file_name and also seems to be functional 
> (under its
> | new name).
> |
> | So apparently, gnulib (or one of those autotools) thinks it needs to 
> replace the
> | canonicalize_file_name function. Also the actual syscall seems to work. 
> However,
> | the macro defined in stdlib.h seems to also affect the definition of the
> | corresponding octave function. Can this last somehow be avoided?
>
> Yes, we need to use DEFUNX in cases like this.  I checked in the
> following change:
>
>  http://hg.savannah.gnu.org/hgweb/octave/rev/14eba566f9f0
>
> Unfortunately, I don't know a good way to discover these problems on
> my own system where such replacements are not necessary.

It seems that under certain circumstances gnulib may redefine other
system names like fprintf, popen etc.

>  Or, maybe we
> should just convert all DEFUNs to DEFUNX in the Octave internals?
>
> jwe
>

I think redefining common names by macros is bad in general, and it
makes code a mess.
We now have many names randomly prefixed by x, such as xabs, xlog2,
xround ... probably because of some supposed macro conflict (which may
not even exist). We have xisalnum, xisdigit etc, just because isascii
and toascii might be defined as macros in cctype. (because they're not
in std::, the other macros must be un#defined).

Ways out?

Perhaps we could do something like

#include <stdio.h> // from gnulib
#ifdef fprintf
int gnulib_fprintf (FILE *f, const char *fmt, ...)
{
  return fprintf (...);
}

admittedly, this requires vsprintf, not printf. Hmmm.
Perhaps gnulib could be somehow persuaded to not redefine the standard
names, but instead define gnulib_printf,
gnulib_canonicalize_file_name, etc?

Hmmm again. Maybe I should just learn to live with all the mangled names.

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