Re: c22219b8a6a6 throws an error on Mac OS X

[Rik]

On 01/02/2016 06:05 PM, Ben Abbott wrote:
>> On Jan 2, 2016, at 20:55, Rik <address@hidden> wrote:
>>
>>> On 01/02/2016 01:28 PM, Ben Abbott wrote:
>>> Rik,
>>>
>>> Your recent changeset c22219b8a6a6 throws an error for Mac OS X.
>>>
>>> In file included from libinterp/octave.cc:72:
>>> In file included from ./libinterp/octave-value/ov-range.h:41:
>>> In file included from ./libinterp/octave-value/ov-re-mat.h:38:
>>> ./libinterp/octave-value/ov-base-mat.h:97:8: warning: 
>>> 'octave_base_matrix<NDArray>::assign' hides overloaded virtual function 
>>> [-Woverloaded-virtual]
>>>  void assign (const octave_value_list& idx, typename MT::element_type rhs);
>>>       ^
>>> ./libinterp/octave-value/ov-base.h:278:16: note: hidden overloaded virtual 
>>> function 'octave_base_value::assign' declared here: type mismatch at 1st 
>>> parameter ('const std::string &'
>>>      (aka 'const basic_string<char, char_traits<char>, allocator<char> > 
>>> &') vs 'const octave_value_list &')
>>>  virtual void assign (const std::string&, const octave_value&) { }
>>>               ^
>>> libinterp/octave.cc:484:3: error: no matching function for call to 
>>> 'set_liboctave_error_handler'
>>>  set_liboctave_error_handler (lo_error_handler);
>>>  ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> ./liboctave/cruft/misc/lo-error.h:56:23: note: candidate function not 
>>> viable: no known conversion from 'void (const char *, ...)' to 
>>> 'liboctave_error_handler' (aka
>>>      'void (*)(const char *, ...) __attribute__((noreturn))') for 1st 
>>> argument
>>> CRUFT_API extern void set_liboctave_error_handler (liboctave_error_handler 
>>> f);
>>>                      ^
>>> libinterp/octave.cc:485:3: error: no matching function for call to 
>>> 'set_liboctave_error_with_id_handler'
>>>  set_liboctave_error_with_id_handler (lo_error_with_id_handler);
>>>  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> ./liboctave/cruft/misc/lo-error.h:58:23: note: candidate function not 
>>> viable: no known conversion from 'void (const char *, const char *, ...)' 
>>> to 'liboctave_error_with_id_handler'
>>>      (aka 'void (*)(const char *, const char *, ...) 
>>> __attribute__((noreturn))') for 1st argument
>>> CRUFT_API extern void set_liboctave_error_with_id_handler 
>>> (liboctave_error_with_id_handler f);
>>>                      ^
>>> 2 warnings and 2 errors generated.
>>> Makefile:18032: recipe for target 
>>> 'libinterp/libinterp_liboctinterp_la-octave.lo' failed
>>> make[2]: *** [libinterp/libinterp_liboctinterp_la-octave.lo] Error 1
>>> make[2]: Leaving directory 
>>> '/Users/bpabbott/Development/mercurial/default/sources'
>>> Makefile:25846: recipe for target 'all-recursive' failed
>>> make[1]: *** [all-recursive] Error 1
>>> make[1]: Leaving directory 
>>> '/Users/bpabbott/Development/mercurial/default/sources'
>>> Makefile:9937: recipe for target 'all' failed
>>> make: *** [all] Error 2
>> Are you using clang or gcc?  And if gcc, what version?
>>
>> --Rik
> Clang ... Apple's version.

So there's a problem.  The GCC_ATTR_NORETURN is only supposed to be used if
you are compiling with gcc.  The code is in oct-conf-post.h.

#if defined (__GNUC__)
#define GCC_ATTR_DEPRECATED __attribute__ ((__deprecated__))
#define HAVE_ATTR_DEPRECATED

#define GCC_ATTR_NORETURN __attribute__ ((__noreturn__))
#define HAVE_ATTR_NORETURN

You could check whether __GNUC__ is really defined by adding

#if defined (__GNUC__)
#error __GNUC__ is defined, but I'm not GCC!
#endif

to some file and then trying to run a compile.  It should error out during
the compile with the error message.

I really wish clang would not pretend to be gcc, but this seems to have
been reported in other places.  See
http://clang-developers.42468.n3.nabble.com/Disable-GNU-defines-in-Clang-td4030764.html
and
http://stackoverflow.com/questions/28166565/detect-gcc-as-opposed-to-msvc-clang-with-macro.
 
I'm CC'ing the Octave-Maintainer's list because this appears to be only the
tip of the iceberg.  We don't use __GNUC__ too frequently, but maybe we
need to rework each instance where it is used and start checking in
addition for __clang__.  Or maybe we should be using #undef __GNUC__ just
once when __clang__ is detected.  I don't really know.

--Rik