Thu 17 Aug 2017 05:03:53 PM UTC, comment #9:
Buildbots are happy and sschoeps reported it fixed the build on macOS, closing as fixed.
|
Wed 16 Aug 2017 11:16:45 PM UTC, comment #8:
Ok, I went ahead and pushed this on the default branch, I'll check with the buildbots in a while
https://hg.savannah.gnu.org/hgweb/octave/rev/0519eaf0cca6
|
Wed 16 Aug 2017 10:53:13 PM UTC, comment #7:
I can clang 4.0.1 compile with (file #41548) patch
(on linux).
Dmitri
|
Wed 16 Aug 2017 09:47:07 PM UTC, comment #6:
I managed to break out of the compile by killing 7 or 8 stalled octave processes:
Then ran 'make' again with no "-j8"
GEN libinterp/builtin-defun-decls.h
GEN doc/interpreter/voronoi.txt
GEN doc/interpreter/triplot.txt
GEN doc/interpreter/griddata.txt
GEN doc/interpreter/convhull.txt
GEN doc/interpreter/delaunay.txt
GEN doc/interpreter/interpft.txt
GEN doc/interpreter/interpn.txt
MAKEINFO /home/sebald/octave/octave/octave/doc/interpreter/octave.info
and the documentation completed and program runs. I'm guessing that
TEXI2PDF doc/interpreter/octave.pdf
jumped ahead of the octave processes completing that final batch of doc generations causing some complication with "make". Not sure this is an Octave issue.
|
Wed 16 Aug 2017 09:40:16 PM UTC, comment #5:
Thanks, updated patch attached. Waiting for some affirmative feedback from macOS users also.
(file #41548)
|
Wed 16 Aug 2017 09:35:46 PM UTC, comment #4:
The patch compiles past the file-io.cc errors. However, there is another:
I did the same thing as in the attached patch with the dmperm.cc file, i.e.,
and compilation makes it all the way through...wuup, not quite--looks like it is stuck on
of all things, no CPU being used or anything.
Anyway, I didn't look to closely what the return value means in the particular cases and will leave that up to you.
|
Wed 16 Aug 2017 09:09:10 PM UTC, comment #3:
I think it is gcc. I will confirm in just a bit, as more info comes out after I started a compilation again (I had to remove -j8 because of a complaint about dependence on an unfinished process, so it is much slower).
I managed to make the compilation continue with
So, it is that particular format, whereas all other uses of ovl seems fine. os is a stream operating on the "who" file, but I don't know what oscanf() is returning.
|
Wed 16 Aug 2017 09:02:29 PM UTC, comment #2:
Try the attached patch.
(file #41547)
|
Wed 16 Aug 2017 08:53:50 PM UTC, comment #1:
What version of gcc or other compiler are you building with?
This was an intentional change, and some instances of constructing an octave_value_list were probably missed, with different versions of gcc and clang having problems resolving overloads with certain combinations of arguments.
Does simply dropping the "ovl" from file-io.cc line 1003 fix this for you? Any other errors?
|
Wed 16 Aug 2017 07:06:41 PM UTC, original submission:
I'm seeing a compilation error (using configure --without-osmesa --no-recursion):
This probably has to do with the recent template expansions and appears to have something to do with this convenience function:
|