octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rpl_canonicalize_file_name blues (while building octave)


From: Thorsten Meyer
Subject: Re: rpl_canonicalize_file_name blues (while building octave)
Date: Wed, 03 Feb 2010 20:23:13 +0100
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)

Hi,

John W. Eaton 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
>   
works like a charm. Thanks a lot.

regards

Thorsten


reply via email to

[Prev in Thread] Current Thread [Next in Thread]