Re: Octave 4.0 on Mac 10.10

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

Jordi Gutiérrez Hermoso-2
Moving this discussion to the maintainers' list...

On Fri, 2015-02-27 at 00:45 -0800, Sebastian Schöps wrote:
> What is the plan for 4.0?

Currently, nothing. We'll ship Octave 4.0 with Windows binaries but no
Mac OS X distribution. Some people have offered to help, but no
concrete results yet:

    http://octave.1599824.n4.nabble.com/Mac-OS-X-champion-td4668534.html   

Mac OS X has a long and awful history with Octave. If you are willing
to put the effort into making reproducible Mac OS X builds for Octave,
it would make a lot of Mac users happy. If you can't ensure
reproducible builds, then an ad-hoc build like the one we had for
3.4.0 could be the next best thing.

- Jordi G. H.



Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

Marius Schamschula-5
A couple of questions:

1) As there seems not to currently be a 4.0.0-rc tag, am I correct to assume that the OS X builds of octave 4.0 are from tip?

2) If so, tip also currently fails to compile on Mavericks (using MacPorts and Xcode 6.1) with the +atlas +gcc48 +glgui +gui +qtgui variants (default for current MP octave 3.8.2, except for the older gcc):

In file included from corefcn/oct-obj.h:33:
./octave-value/ov.h:1071:37: error: friend declaration specifying a default argument must be a definition
  friend OCTINTERP_API octave_value do_colon_op (const octave_value& base,
                                    ^
  GEN      dldfcn/__init_fltk__.df
In file included from builtins.cc:7:
In file included from corefcn/defun.h:30:
In file included from corefcn/defun-int.h:28:
In file included from ./octave-value/ov-builtin.h:28:
In file included from ./octave-value/ov-fcn.h:31:
In file included from corefcn/oct-obj.h:33:
./octave-value/ov.h:1071:37: error: friend declaration specifying a default argument must be a definition
  friend OCTINTERP_API octave_value do_colon_op (const octave_value& base,
                                    ^
  GEN      dldfcn/__init_gnuplot__.df
  GEN      dldfcn/__magick_read__.df
In file included from corefcn/oct-errno.cc:32:
In file included from corefcn/oct-errno.h:31:
In file included from corefcn/oct-map.h:30:
In file included from corefcn/Cell.h:31:
./octave-value/ov.h:1071:37: error: friend declaration specifying a default argument must be a definition
  friend OCTINTERP_API octave_value do_colon_op (const octave_value& base,
                                    ^
1 error generated.
make[3]: *** [corefcn/liboctinterp_la-oct-errno.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from octave.cc:35:
In file included from /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/iostream:38:
In file included from /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/ios:216:
In file included from /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/__locale:15:
In file included from /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/string:439:
In file included from /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/algorithm:626:
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/utility:253:9: error: field has incomplete type 'const cdef_class'
    _T1 first;
        ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:629:16: note: in instantiation of template class 'std::__1::pair<const cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >' requested here
    value_type __cc;
               ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/__tree:603:16: note: in instantiation of template class 'std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >' requested here
    value_type __value_;
               ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/__tree:694:22: note: in instantiation of template class 'std::__1::__tree_node<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, void *>' requested here
    typedef typename __node::base                                 __node_base;
                     ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:715:19: note: in instantiation of template class 'std::__1::__tree_const_iterator<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::__tree_node<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, void *> *, long>' requested here
    _TreeIterator __i_;
                  ^
./octave-value/ov-classdef.h:441:71: note: in instantiation of template class 'std::__1::__map_const_iterator<std::__1::__tree_const_iterator<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::__tree_node<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, void *> *, long> >' requested here
  void mark_as_constructed (const cdef_class& cls) { ctor_list.erase (cls); }
                                                                      ^
./octave-value/ov-classdef.h:36:7: note: forward declaration of 'cdef_class'
class cdef_class;
      ^
In file included from octave.cc:72:
In file included from ./octave-value/ov-range.h:41:
In file included from ./octave-value/ov-re-mat.h:38:
./octave-value/ov-base-mat.h:95:8: warning: 'octave_base_matrix<NDArray>::assign' hides overloaded virtual function [-Woverloaded-virtual]
  void assign (const octave_value_list& idx, const MT& rhs);
       ^
./octave-value/ov-re-mat.h:51:24: note: in instantiation of template class 'octave_base_matrix<NDArray>' requested here
octave_matrix : public octave_base_matrix<NDArray>
                       ^
./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&) { }
               ^
In file included from octave.cc:72:
In file included from ./octave-value/ov-range.h:41:
In file included from ./octave-value/ov-re-mat.h:38:
./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);
       ^
./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&) { }
               ^
1 error generated.
make[3]: *** [liboctinterp_la-builtins.lo] Error 1
In file included from octave.cc:42:
In file included from ../liboctave/util/cmd-edit.h:28:
In file included from /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/set:387:
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/__tree:1985:19: error: static_cast from '__node_pointer' (aka 'std::__1::__tree_node<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, void *> *') to '__node_base_pointer' (aka 'std::__1::__tree_node_base<void *> *') is not allowed
                  static_cast<__node_base_pointer>(__np));
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/__tree:2007:5: note: in instantiation of member function 'std::__1::__tree<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::__map_value_compare<cdef_class, std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::less<cdef_class>, true>, std::__1::allocator<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::erase' requested here
    erase(__i);
    ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:1068:25: note: in instantiation of function template specialization 'std::__1::__tree<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::__map_value_compare<cdef_class, std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::less<cdef_class>, true>, std::__1::allocator<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::__erase_unique<cdef_class>' requested here
        {return __tree_.__erase_unique(__k);}
                        ^
./octave-value/ov-classdef.h:441:64: note: in instantiation of member function 'std::__1::map<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> >, std::__1::less<cdef_class>, std::__1::allocator<std::__1::pair<const cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::erase' requested here
  void mark_as_constructed (const cdef_class& cls) { ctor_list.erase (cls); }
                                                               ^
In file included from octave.cc:42:
In file included from ../liboctave/util/cmd-edit.h:28:
In file included from /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/set:387:
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/__tree:656:59: error: static_cast from '__node_pointer' (aka 'std::__1::__tree_node<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, void *> *') to '__node_base_pointer' (aka 'std::__1::__tree_node_base<void *> *') is not allowed
        {__ptr_ = static_cast<__node_pointer>(__tree_next(static_cast<__node_base_pointer>(__ptr_)));
                                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/__tree:1978:5: note: in instantiation of member function 'std::__1::__tree_iterator<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::__tree_node<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, void *> *, long>::operator++' requested here
    ++__r;
    ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/__tree:2007:5: note: in instantiation of member function 'std::__1::__tree<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::__map_value_compare<cdef_class, std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::less<cdef_class>, true>, std::__1::allocator<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::erase' requested here
    erase(__i);
    ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:1068:25: note: in instantiation of function template specialization 'std::__1::__tree<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::__map_value_compare<cdef_class, std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::less<cdef_class>, true>, std::__1::allocator<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::__erase_unique<cdef_class>' requested here
        {return __tree_.__erase_unique(__k);}
                        ^
./octave-value/ov-classdef.h:441:64: note: in instantiation of member function 'std::__1::map<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> >, std::__1::less<cdef_class>, std::__1::allocator<std::__1::pair<const cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::erase' requested here
  void mark_as_constructed (const cdef_class& cls) { ctor_list.erase (cls); }
                                                               ^
In file included from octave.cc:53:
In file included from corefcn/defun.h:30:
In file included from corefcn/defun-int.h:28:
In file included from ./octave-value/ov-builtin.h:28:
In file included from ./octave-value/ov-fcn.h:34:
In file included from corefcn/symtab.h:29:
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:967:50: error: no viable conversion from 'const_iterator' (aka '__tree_const_iterator<value_type, __node_pointer, difference_type>') to 'const_iterator' (aka '__map_const_iterator<typename __base::const_iterator>')
    const_iterator end() const _NOEXCEPT {return __tree_.end();}
                                                 ^~~~~~~~~~~~~
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:878:37: note: in instantiation of member function 'std::__1::map<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> >, std::__1::less<cdef_class>, std::__1::allocator<std::__1::pair<const cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::end' requested here
            insert(__m.begin(), __m.end());
                                    ^
./octave-value/ov-classdef.h:455:46: note: in instantiation of member function 'std::__1::map<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> >, std::__1::less<cdef_class>, std::__1::allocator<std::__1::pair<const cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::map' requested here
    : cdef_object_base (obj), map (obj.map), ctor_list (obj.ctor_list) { }
                                             ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:713:29: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'const_iterator' (aka '__tree_const_iterator<value_type, __node_pointer, difference_type>') to 'const std::__1::__map_const_iterator<std::__1::__tree_const_iterator<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::__tree_node<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, void *> *, long> > &' for 1st argument
class _LIBCPP_TYPE_VIS_ONLY __map_const_iterator
                            ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:739:5: note: candidate constructor not viable: no known conversion from 'const_iterator' (aka '__tree_const_iterator<value_type, __node_pointer, difference_type>') to '__map_iterator<typename __tree_const_iterator<__value_type<cdef_class, list<cdef_class, allocator<cdef_class> > >, __tree_node<__value_type<cdef_class, list<cdef_class, allocator<cdef_class> > >, void *> *, long>::__non_const_iterator>' for 1st argument
    __map_const_iterator(
    ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:984:51: error: member function 'end' not viable: 'this' argument has type 'const std::__1::map<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> >, std::__1::less<cdef_class>, std::__1::allocator<std::__1::pair<const cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >', but function is not marked const
    const_iterator cend() const _NOEXCEPT {return end();}
                                                  ^~~
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:1052:39: note: in instantiation of member function 'std::__1::map<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> >, std::__1::less<cdef_class>, std::__1::allocator<std::__1::pair<const cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::cend' requested here
            for (const_iterator __e = cend(); __f != __l; ++__f)
                                      ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:878:13: note: in instantiation of function template specialization 'std::__1::map<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> >, std::__1::less<cdef_class>, std::__1::allocator<std::__1::pair<const cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::insert<std::__1::__map_const_iterator<std::__1::__tree_const_iterator<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, std::__1::__tree_node<std::__1::__value_type<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > >, void *> *, long> > >' requested here
            insert(__m.begin(), __m.end());
            ^
./octave-value/ov-classdef.h:455:46: note: in instantiation of member function 'std::__1::map<cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> >, std::__1::less<cdef_class>, std::__1::allocator<std::__1::pair<const cdef_class, std::__1::list<cdef_class, std::__1::allocator<cdef_class> > > > >::map' requested here
    : cdef_object_base (obj), map (obj.map), ctor_list (obj.ctor_list) { }
                                             ^
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/map:965:20: note: 'end' declared here
          iterator end() _NOEXCEPT {return __tree_.end();}
                   ^
2 warnings and 6 errors generated.


On Feb 27, 2015, at 8:42 AM, Jordi Gutiérrez Hermoso <[hidden email]> wrote:

Moving this discussion to the maintainers' list...

On Fri, 2015-02-27 at 00:45 -0800, Sebastian Schöps wrote:
What is the plan for 4.0?

Currently, nothing. We'll ship Octave 4.0 with Windows binaries but no
Mac OS X distribution. Some people have offered to help, but no
concrete results yet:

   http://octave.1599824.n4.nabble.com/Mac-OS-X-champion-td4668534.html    

Mac OS X has a long and awful history with Octave. If you are willing
to put the effort into making reproducible Mac OS X builds for Octave,
it would make a lot of Mac users happy. If you can't ensure
reproducible builds, then an ad-hoc build like the one we had for
3.4.0 could be the next best thing.

- Jordi G. H.




Marius
--
Marius Schamschula




Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

bpabbott
Administrator
> On Feb 27, 2015, at 2:45 PM, Marius Schamschula <[hidden email]> wrote:
>
> A couple of questions:
>
> 1) As there seems not to currently be a 4.0.0-rc tag, am I correct to assume that the OS X builds of octave 4.0 are from tip?

If you are building using a local mercurial archive, I suggest you use a shell script and skip the port files.

Before switching to Yosemite and Fink, I configured with the options below (using Macports on Mavericks). I made my switch in November. Until then this worked for me.

GCCVER=4.8
CCACHE="ccache"
./configure                                               \
   CC=/opt/local/bin/clang-mp-3.4                         \
   CFLAGS="-pipe -O2 -m64 -g -arch x86_64"                \
   LDFLAGS="-L/opt/local/lib -L/opt/X11/lib"         \
   CXX=/opt/local/bin/clang-mp-3.4                        \
   CXXFLAGS="-pipe -O2 -m64 -arch x86_64"                 \
   CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include -I/opt/X11/include"  \
   FC="ccache gfortran-mp-$GCCVER"                        \
   F77="ccache gfortran-mp-$GCCVER"                       \
   FFLAGS="-pipe -O2 -m64 -arch x86_64"                   \
   LLVM_CONFIG="$(which llvm-config-mp-3.4)"              \
   CARBON_LIBS="-Wl,-framework -Wl,Carbon"                \
   LIBS="-Wl,-framework -Wl,Carbon"                       \
   --disable-bounds-check                                 \
   --disable-jit                                          \
   --with-magick=GraphicsMagick                           \
   --with-lapack="-llapack -latlas -lgfortran"            \
   --with-blas="-lcblas -lf77blas -latlas -lgfortran"     \
   --prefix=/usr/local/octave/4.1.0                       \
   --disable-java                                         \
   --with-arpack                                          \
   --enable-docs                                          \
   --enable-gui                                           \
   --with-opengl                                          \
   --with-framework-carbon                                \
   --without-x                                            \
   --enable-link-all-dependencies

Ben
Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

Sebastian Schöps
bpabbott wrote
./configure                                               \
   CC=/opt/local/bin/clang-mp-3.4                         \
i.e. you are using Macport's clang instead of gcc... could you try to use Macport's gcc instead? I used to compile Octave with gcc but since I switched to homebrew I am with clang.

As I have written in my former post most errors seem to be induced by LLVM/clang:
http://savannah.gnu.org/bugs/?41178 (all versions?)
http://savannah.gnu.org/bugs/?41061 (v3.5)
http://savannah.gnu.org/bugs/?43298 (v3.5)

Seb.
Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

Sebastian Schöps
In reply to this post by Jordi Gutiérrez Hermoso-2
Jordi Gutiérrez Hermoso-2 wrote
Moving this discussion to the maintainers' list...

On Fri, 2015-02-27 at 00:45 -0800, Sebastian Schöps wrote:
> What is the plan for 4.0?

Currently, nothing. We'll ship Octave 4.0 with Windows binaries but no
Mac OS X distribution. Some people have offered to help, but no
concrete results yet:

    http://octave.1599824.n4.nabble.com/Mac-OS-X-champion-td4668534.html   
I was aware of these discussions (I think I was even involved) and yes, I should have posted using the previous subject. However, there was no conclusion? Maybe we (I?) should update the wiki page for the Mac to keep records what is currently working.
Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

bpabbott
Administrator
In reply to this post by Sebastian Schöps
> On Feb 28, 2015, at 4:49 AM, Sebastian Schöps <[hidden email]> wrote:
>
> bpabbott wrote
>> ./configure                                               \
>>  CC=/opt/local/bin/clang-mp-3.4                         \
>
> i.e. you are using Macport's clang instead of gcc... could you try to use
> Macport's gcc instead? I used to compile Octave with gcc but since I
> switched to homebrew I am with clang.
>
> As I have written in my former post most errors seem to be induced by
> LLVM/clang:
> http://savannah.gnu.org/bugs/?41178 (all versions?)
> http://savannah.gnu.org/bugs/?41061 (v3.5)
> http://savannah.gnu.org/bugs/?43298 (v3.5)
>
> Seb.

Opps. I had been using gcc on Mavericks. I expect I switched to clang when I upgraded to Yosemite (which never worked for me).

I think Carlo is still able to build the default tip on Mavericks and using Macports. Perhaps he can confirm the comment on how he configure's Octave.

Ben


Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

Carlo de Falco-2

On 28 Feb 2015, at 16:54, Ben Abbott <[hidden email]> wrote:

> Opps. I had been using gcc on Mavericks. I expect I switched to clang when I upgraded to Yosemite (which never worked for me).
>
> I think Carlo is still able to build the default tip on Mavericks and using Macports. Perhaps he can confirm the comment on how he configure's Octave.

Yes, I am using macports but I have to patch a few portfiles to make it work.
In particular I have to fix the Qscintilla version at 2.7.2.
Most other changes are to make sure that packages that do not have
a gcc49 variant are built with gcc rather than clang.
It has been my intention for a long while to document all those changes
in detail, but I never got time to do it.

Once the dependencies are in place I configure with:

../octave/configure                                    \
    CC=gcc                                             \
    CFLAGS="-pipe -O2 -m64"                            \
    CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include"     \
    LDFLAGS="-L/opt/local/lib -m64 "                   \
    CXX=g++                                            \
    CXXFLAGS="-pipe -O2 -m64"                          \
    F77=gfortran                                       \
    FFLAGS="-pipe -O2 -m64"                            \
    LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.4      \
    --with-lapack="-llapack -latlas -lgfortran"        \
    --with-blas="-lcblas -lf77blas -latlas -lgfortran" \
    --prefix=/opt/octave/4.1                           \
    --enable-gui                                       \
    --disable-jit                                      \
    --disable-java                                     \
    --with-framework-carbon                            \
    --with-arpack                                      \
    --enable-docs                                      \
    --with-opengl                                      \
    --without-x                                        \
    --enable-link-all-dependencies

I don't even remeber the reason for some of the flags,
I guess many were inherited from Ben's examples.

> Ben
c.
Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

rdzman
In reply to this post by Jordi Gutiérrez Hermoso-2
FWIW, I have Yosemite 10.10.2 installed and an up-to-date MacPorts and corresponding working build of Octave 3.8.2.

I don't have a ton of time, but I'm happy to try a few builds of 4.0 if someone wants to give me specific configure options to attempt. I assume ...

hg clone http://www.octave.org/hg/octave

... gets me the latest 4.0 source, right? I did also attempt a naive build of that unsuccessfully.

 - Ray
Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

Marius Schamschula-5
In reply to this post by Carlo de Falco-2
On Mar 1, 2015, at 10:44 PM, Carlo De Falco <[hidden email]> wrote:

>
> On 28 Feb 2015, at 16:54, Ben Abbott <[hidden email]> wrote:
>
>> Opps. I had been using gcc on Mavericks. I expect I switched to clang when I upgraded to Yosemite (which never worked for me).
>>
>> I think Carlo is still able to build the default tip on Mavericks and using Macports. Perhaps he can confirm the comment on how he configure's Octave.
>
> Yes, I am using macports but I have to patch a few portfiles to make it work.
> In particular I have to fix the Qscintilla version at 2.7.2.
> Most other changes are to make sure that packages that do not have
> a gcc49 variant are built with gcc rather than clang.
> It has been my intention for a long while to document all those changes
> in detail, but I never got time to do it.
>
> Once the dependencies are in place I configure with:
>
> ../octave/configure                                    \
>    CC=gcc                                             \
>    CFLAGS="-pipe -O2 -m64"                            \
>    CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include"     \
>    LDFLAGS="-L/opt/local/lib -m64 "                   \
>    CXX=g++                                            \
>    CXXFLAGS="-pipe -O2 -m64"                          \
>    F77=gfortran                                       \
>    FFLAGS="-pipe -O2 -m64"                            \
>    LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.4      \
>    --with-lapack="-llapack -latlas -lgfortran"        \
>    --with-blas="-lcblas -lf77blas -latlas -lgfortran" \
>    --prefix=/opt/octave/4.1                           \
>    --enable-gui                                       \
>    --disable-jit                                      \
>    --disable-java                                     \
>    --with-framework-carbon                            \
>    --with-arpack                                      \
>    --enable-docs                                      \
>    --with-opengl                                      \
>    --without-x                                        \
>    --enable-link-all-dependencies
>
> I don't even remeber the reason for some of the flags,
> I guess many were inherited from Ben's examples.
>
>> Ben
> c.

Last night I did a bit more test compiling. I ran into the well known issue with osmesa, so I disabled it. Apparently the MacPorts install of mesa +osmesa does not install a consistent set of header files.

Now I’m dealing with the following issue:

Making all in libgui
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
  CXX      src/m-editor/src_libgui_src_la-file-editor-tab.lo
In file included from ../libgnu/stdio.h:43:0,
                 from ../libgnu/wchar.h:71,
                 from /opt/local/include/gcc48/c++/cwchar:44,
                 from /opt/local/include/gcc48/c++/bits/postypes.h:40,
                 from /opt/local/include/gcc48/c++/bits/char_traits.h:40,
                 from /opt/local/include/gcc48/c++/string:40,
                 from /opt/local/include/QtCore/qstring.h:54,
                 from /opt/local/include/QtCore/qobject.h:48,
                 from /opt/local/include/Qsci/qscilexeroctave.h:33,
                 from src/m-editor/file-editor-tab.cc:32:
/usr/include/stdio.h:255:7: error: previous declaration of 'char* gets(char*)' with 'C' linkage
 char *gets(char *);
       ^
In file included from /opt/local/include/gcc48/c++/cstdlib:72:0,
                 from /opt/local/include/gcc48/c++/bits/stl_algo.h:59,
                 from /opt/local/include/gcc48/c++/algorithm:62,
                 from /opt/local/include/QtCore/qglobal.h:68,
                 from /opt/local/include/QtCore/qnamespace.h:45,
                 from /opt/local/include/QtCore/qobjectdefs.h:45,
                 from /opt/local/include/QtCore/qobject.h:47,
                 from /opt/local/include/Qsci/qscilexeroctave.h:33,
                 from src/m-editor/file-editor-tab.cc:32:
../libgnu/stdio.h:1039:1: error: conflicts with new declaration with 'C++' linkage
 _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
 ^
make[3]: *** [src/m-editor/src_libgui_src_la-file-editor-tab.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Marius
--
Marius Schamschula





Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

Eugenio Gianniti

> On 03 Mar 2015, at 23:32, Marius Schamschula <[hidden email]> wrote:
>
> On Mar 1, 2015, at 10:44 PM, Carlo De Falco <[hidden email]> wrote:
>
>>
>> On 28 Feb 2015, at 16:54, Ben Abbott <[hidden email]> wrote:
>>
>>> Opps. I had been using gcc on Mavericks. I expect I switched to clang when I upgraded to Yosemite (which never worked for me).
>>>
>>> I think Carlo is still able to build the default tip on Mavericks and using Macports. Perhaps he can confirm the comment on how he configure's Octave.
>>
>> Yes, I am using macports but I have to patch a few portfiles to make it work.
>> In particular I have to fix the Qscintilla version at 2.7.2.
>> Most other changes are to make sure that packages that do not have
>> a gcc49 variant are built with gcc rather than clang.
>> It has been my intention for a long while to document all those changes
>> in detail, but I never got time to do it.
>>
>> Once the dependencies are in place I configure with:
>>
>> ../octave/configure                                    \
>>   CC=gcc                                             \
>>   CFLAGS="-pipe -O2 -m64"                            \
>>   CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include"     \
>>   LDFLAGS="-L/opt/local/lib -m64 "                   \
>>   CXX=g++                                            \
>>   CXXFLAGS="-pipe -O2 -m64"                          \
>>   F77=gfortran                                       \
>>   FFLAGS="-pipe -O2 -m64"                            \
>>   LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.4      \
>>   --with-lapack="-llapack -latlas -lgfortran"        \
>>   --with-blas="-lcblas -lf77blas -latlas -lgfortran" \
>>   --prefix=/opt/octave/4.1                           \
>>   --enable-gui                                       \
>>   --disable-jit                                      \
>>   --disable-java                                     \
>>   --with-framework-carbon                            \
>>   --with-arpack                                      \
>>   --enable-docs                                      \
>>   --with-opengl                                      \
>>   --without-x                                        \
>>   --enable-link-all-dependencies
>>
>> I don't even remeber the reason for some of the flags,
>> I guess many were inherited from Ben's examples.
>>
>>> Ben
>> c.
>
> Last night I did a bit more test compiling. I ran into the well known issue with osmesa, so I disabled it. Apparently the MacPorts install of mesa +osmesa does not install a consistent set of header files.
>
> Now I’m dealing with the following issue:
>
> Making all in libgui
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
>  CXX      src/m-editor/src_libgui_src_la-file-editor-tab.lo
> In file included from ../libgnu/stdio.h:43:0,
>                 from ../libgnu/wchar.h:71,
>                 from /opt/local/include/gcc48/c++/cwchar:44,
>                 from /opt/local/include/gcc48/c++/bits/postypes.h:40,
>                 from /opt/local/include/gcc48/c++/bits/char_traits.h:40,
>                 from /opt/local/include/gcc48/c++/string:40,
>                 from /opt/local/include/QtCore/qstring.h:54,
>                 from /opt/local/include/QtCore/qobject.h:48,
>                 from /opt/local/include/Qsci/qscilexeroctave.h:33,
>                 from src/m-editor/file-editor-tab.cc:32:
> /usr/include/stdio.h:255:7: error: previous declaration of 'char* gets(char*)' with 'C' linkage
> char *gets(char *);
>       ^
> In file included from /opt/local/include/gcc48/c++/cstdlib:72:0,
>                 from /opt/local/include/gcc48/c++/bits/stl_algo.h:59,
>                 from /opt/local/include/gcc48/c++/algorithm:62,
>                 from /opt/local/include/QtCore/qglobal.h:68,
>                 from /opt/local/include/QtCore/qnamespace.h:45,
>                 from /opt/local/include/QtCore/qobjectdefs.h:45,
>                 from /opt/local/include/QtCore/qobject.h:47,
>                 from /opt/local/include/Qsci/qscilexeroctave.h:33,
>                 from src/m-editor/file-editor-tab.cc:32:
> ../libgnu/stdio.h:1039:1: error: conflicts with new declaration with 'C++' linkage
> _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
> ^
> make[3]: *** [src/m-editor/src_libgui_src_la-file-editor-tab.lo] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
When I incurred in the same problem I solved the issue with the attached patch,
in my case using Homebrew.
In my understanding the headers are too zealously wrapped in extern “C++” blocks,
hence basic C headers contents are included as both C and C++ functions.
Probably moving the opening lines after all the includes could be enough, but I adopted
the straightforward approach of just deleting them.

HTH,
Eugenio



qscintilla2_Qt4Qt5__APPLE__patch.diff (32K) Download Attachment
ATT00001.txt (92 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

Marius Schamschula-5

On Mar 3, 2015, at 4:56 PM, Eugenio Gianniti <[hidden email]> wrote:


On 03 Mar 2015, at 23:32, Marius Schamschula <[hidden email]> wrote:

On Mar 1, 2015, at 10:44 PM, Carlo De Falco <[hidden email]> wrote:


On 28 Feb 2015, at 16:54, Ben Abbott <[hidden email]> wrote:

Opps. I had been using gcc on Mavericks. I expect I switched to clang when I upgraded to Yosemite (which never worked for me).

I think Carlo is still able to build the default tip on Mavericks and using Macports. Perhaps he can confirm the comment on how he configure's Octave.

Yes, I am using macports but I have to patch a few portfiles to make it work.
In particular I have to fix the Qscintilla version at 2.7.2.
Most other changes are to make sure that packages that do not have 
a gcc49 variant are built with gcc rather than clang.
It has been my intention for a long while to document all those changes 
in detail, but I never got time to do it.

Once the dependencies are in place I configure with:

../octave/configure                                    \
 CC=gcc                                             \
 CFLAGS="-pipe -O2 -m64"                            \
 CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include"     \
 LDFLAGS="-L/opt/local/lib -m64 "                   \
 CXX=g++                                            \
 CXXFLAGS="-pipe -O2 -m64"                          \
 F77=gfortran                                       \
 FFLAGS="-pipe -O2 -m64"                            \
 LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.4      \
 --with-lapack="-llapack -latlas -lgfortran"        \
 --with-blas="-lcblas -lf77blas -latlas -lgfortran" \
 --prefix=/opt/octave/4.1                           \
 --enable-gui                                       \
 --disable-jit                                      \
 --disable-java                                     \
 --with-framework-carbon                            \
 --with-arpack                                      \
 --enable-docs                                      \
 --with-opengl                                      \
 --without-x                                        \
 --enable-link-all-dependencies

I don't even remeber the reason for some of the flags, 
I guess many were inherited from Ben's examples.

Ben
c.

Last night I did a bit more test compiling. I ran into the well known issue with osmesa, so I disabled it. Apparently the MacPorts install of mesa +osmesa does not install a consistent set of header files.

Now I’m dealing with the following issue:

Making all in libgui
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
CXX      src/m-editor/src_libgui_src_la-file-editor-tab.lo
In file included from ../libgnu/stdio.h:43:0,
               from ../libgnu/wchar.h:71,
               from /opt/local/include/gcc48/c++/cwchar:44,
               from /opt/local/include/gcc48/c++/bits/postypes.h:40,
               from /opt/local/include/gcc48/c++/bits/char_traits.h:40,
               from /opt/local/include/gcc48/c++/string:40,
               from /opt/local/include/QtCore/qstring.h:54,
               from /opt/local/include/QtCore/qobject.h:48,
               from /opt/local/include/Qsci/qscilexeroctave.h:33,
               from src/m-editor/file-editor-tab.cc:32:
/usr/include/stdio.h:255:7: error: previous declaration of 'char* gets(char*)' with 'C' linkage
char *gets(char *);
     ^
In file included from /opt/local/include/gcc48/c++/cstdlib:72:0,
               from /opt/local/include/gcc48/c++/bits/stl_algo.h:59,
               from /opt/local/include/gcc48/c++/algorithm:62,
               from /opt/local/include/QtCore/qglobal.h:68,
               from /opt/local/include/QtCore/qnamespace.h:45,
               from /opt/local/include/QtCore/qobjectdefs.h:45,
               from /opt/local/include/QtCore/qobject.h:47,
               from /opt/local/include/Qsci/qscilexeroctave.h:33,
               from src/m-editor/file-editor-tab.cc:32:
../libgnu/stdio.h:1039:1: error: conflicts with new declaration with 'C++' linkage
_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
^
make[3]: *** [src/m-editor/src_libgui_src_la-file-editor-tab.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

When I incurred in the same problem I solved the issue with the attached patch,
in my case using Homebrew.
In my understanding the headers are too zealously wrapped in extern “C++” blocks,
hence basic C headers contents are included as both C and C++ functions.
Probably moving the opening lines after all the includes could be enough, but I adopted
the straightforward approach of just deleting them.

HTH,
Eugenio


<qscintilla2_Qt4Qt5__APPLE__patch.diff>

Thanks Eugenio!

This patch allowed my build to finish.

make test gave me one fail:

 libinterp/corefcn/file-io.cc-tst ............................ PASS      0/1   
                                                                  FAIL    1

On to trying to figure out the osmesa bit…

Marius
--
Marius Schamschula




Reply | Threaded
Open this post in threaded view
|

Re: Octave 4.0 on Mac 10.10

Marius Schamschula-5

On Mar 3, 2015, at 8:40 PM, Marius Schamschula <[hidden email]> wrote:


On Mar 3, 2015, at 4:56 PM, Eugenio Gianniti <[hidden email]> wrote:


On 03 Mar 2015, at 23:32, Marius Schamschula <[hidden email]> wrote:

On Mar 1, 2015, at 10:44 PM, Carlo De Falco <[hidden email]> wrote:


On 28 Feb 2015, at 16:54, Ben Abbott <[hidden email]> wrote:

Opps. I had been using gcc on Mavericks. I expect I switched to clang when I upgraded to Yosemite (which never worked for me).

I think Carlo is still able to build the default tip on Mavericks and using Macports. Perhaps he can confirm the comment on how he configure's Octave.

Yes, I am using macports but I have to patch a few portfiles to make it work.
In particular I have to fix the Qscintilla version at 2.7.2.
Most other changes are to make sure that packages that do not have 
a gcc49 variant are built with gcc rather than clang.
It has been my intention for a long while to document all those changes 
in detail, but I never got time to do it.

Once the dependencies are in place I configure with:

../octave/configure                                    \
 CC=gcc                                             \
 CFLAGS="-pipe -O2 -m64"                            \
 CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include"     \
 LDFLAGS="-L/opt/local/lib -m64 "                   \
 CXX=g++                                            \
 CXXFLAGS="-pipe -O2 -m64"                          \
 F77=gfortran                                       \
 FFLAGS="-pipe -O2 -m64"                            \
 LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.4      \
 --with-lapack="-llapack -latlas -lgfortran"        \
 --with-blas="-lcblas -lf77blas -latlas -lgfortran" \
 --prefix=/opt/octave/4.1                           \
 --enable-gui                                       \
 --disable-jit                                      \
 --disable-java                                     \
 --with-framework-carbon                            \
 --with-arpack                                      \
 --enable-docs                                      \
 --with-opengl                                      \
 --without-x                                        \
 --enable-link-all-dependencies

I don't even remeber the reason for some of the flags, 
I guess many were inherited from Ben's examples.

Ben
c.

Last night I did a bit more test compiling. I ran into the well known issue with osmesa, so I disabled it. Apparently the MacPorts install of mesa +osmesa does not install a consistent set of header files.

Now I’m dealing with the following issue:

Making all in libgui
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
CXX      src/m-editor/src_libgui_src_la-file-editor-tab.lo
In file included from ../libgnu/stdio.h:43:0,
               from ../libgnu/wchar.h:71,
               from /opt/local/include/gcc48/c++/cwchar:44,
               from /opt/local/include/gcc48/c++/bits/postypes.h:40,
               from /opt/local/include/gcc48/c++/bits/char_traits.h:40,
               from /opt/local/include/gcc48/c++/string:40,
               from /opt/local/include/QtCore/qstring.h:54,
               from /opt/local/include/QtCore/qobject.h:48,
               from /opt/local/include/Qsci/qscilexeroctave.h:33,
               from src/m-editor/file-editor-tab.cc:32:
/usr/include/stdio.h:255:7: error: previous declaration of 'char* gets(char*)' with 'C' linkage
char *gets(char *);
     ^
In file included from /opt/local/include/gcc48/c++/cstdlib:72:0,
               from /opt/local/include/gcc48/c++/bits/stl_algo.h:59,
               from /opt/local/include/gcc48/c++/algorithm:62,
               from /opt/local/include/QtCore/qglobal.h:68,
               from /opt/local/include/QtCore/qnamespace.h:45,
               from /opt/local/include/QtCore/qobjectdefs.h:45,
               from /opt/local/include/QtCore/qobject.h:47,
               from /opt/local/include/Qsci/qscilexeroctave.h:33,
               from src/m-editor/file-editor-tab.cc:32:
../libgnu/stdio.h:1039:1: error: conflicts with new declaration with 'C++' linkage
_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
^
make[3]: *** [src/m-editor/src_libgui_src_la-file-editor-tab.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

When I incurred in the same problem I solved the issue with the attached patch,
in my case using Homebrew.
In my understanding the headers are too zealously wrapped in extern “C++” blocks,
hence basic C headers contents are included as both C and C++ functions.
Probably moving the opening lines after all the includes could be enough, but I adopted
the straightforward approach of just deleting them.

HTH,
Eugenio


<qscintilla2_Qt4Qt5__APPLE__patch.diff>

Thanks Eugenio!

This patch allowed my build to finish.

make test gave me one fail:

 libinterp/corefcn/file-io.cc-tst ............................ PASS      0/1   
                                                                  FAIL    1

On to trying to figure out the osmesa bit…

Marius
--
Marius Schamschula

It looks like there is something rather wrong with OSmesa under OS X. I can’t get past the following error:

  CXX      dldfcn/dldfcn___osmesa_print___la-__osmesa_print__.lo
In file included from dldfcn/__osmesa_print__.cc:42:0:
/usr/local/octave/include/GL/osmesa.h:113:1: error: 'GLAPI' does not name a type
 GLAPI OSMesaContext GLAPIENTRY
 ^

even after building a local copy of mesa 10.4.4. I get the same error with the mesa package installed via MacPorts. Has anyone been able to build octave 3.9.1+ with osmesa enabled?

Marius
--
Marius Schamschula