rpl_canonicalize_file_name blues (while building octave)

[John W. Eaton]

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.  Or, maybe we
should just convert all DEFUNs to DEFUNX in the Octave internals?

jwe