bugGNU Octave - Bugs: bug #55187, build: fails to work with Qt 5.12,...

 
 

bug #55187: build: fails to work with Qt 5.12, qcollectiongenerator no longer exists

Submitted by:  Stefan Husmann <haawda>
Submitted on:  Sun 09 Dec 2018 11:50:48 AM UTC  
 
Category:  Configuration and Build System Severity:  4 - Important
Priority:  5 - Normal Item Group:  Build Failure
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 16 May 2019 01:18:25 PM UTC, comment #47: 

Under macOS, to solve this error from configure,

fatal error: 'QtCore/qvariant.h' file not found
#include <QtCore/qvariant.h>

add the following to the configure command line,

CXXFLAGS=-F/location/to/qt/lib

Note that /location/to/qt/lib contains all *.framework libraries.

Albert Jin <albertjin>
Sun 30 Dec 2018 03:04:41 PM UTC, comment #46: 

By "This exists for me know", I mean that the Qt 5.12.0 from Homebrew includes such a structure of symbolic links.

Ben Abbott <bpabbott>
Project Member
Sun 30 Dec 2018 01:55:48 PM UTC, comment #45: 

Looks like the QT_CPPFLAGS problem is because the macOS frameworks makes it problematic to have a root include directory (each Qt module has its own framework bundle).

This can be fixed in a clumsy way by creating a linux style include path using symbolic links. This exists for me know, but isn't available from pkg-config, and I can't tell if it is a creation of Qt or Homebrew.

Ben Abbott <bpabbott>
Project Member
Sun 30 Dec 2018 01:41:51 PM UTC, comment #44: 

So the QT_CPPFLAGS is an upstream package bug in homebrew?  It's fine with me to leave it alone if you agree.

Rik <rik5>
Project Administrator
Sun 30 Dec 2018 01:07:00 PM UTC, comment #43: 

@Rik,

Bug #55282 was initially intended for that. But discussion and my lack of understanding how the flags were used side tracked things.

Ben Abbott <bpabbott>
Project Member
Sun 30 Dec 2018 12:10:04 PM UTC, comment #42: 

@Ben: Could you file a new bug report about Octave not using QT_CPPFLAGS and QT_LDFLAGS for all files that might require them?  I think it is better for us to fix the instances where we have this wrong, rather than add them to the global LDFLAGS and CPPFLAGS variables.

I can't help on this since the compilation works fine for me back with Qt 5.9.5.  However, I would think the loop would be to compile, find the first error, add the QT_CPPFLAGS and QT_LDFLAGS to that target, and then re-try.  I would hope there wouldn't be more than a few instances that need fixing.

Rik <rik5>
Project Administrator
Sun 30 Dec 2018 12:07:04 PM UTC, comment #41: 

@Mike: Is the resolution for this bug report an M4 macro in m4/acinclude.m4 that tries to run qhelpgenerator on a sample file?

I don't necessarily like to do version checking, but it would be easy.  I ran

 /usr/lib/qt5/bin/qhelpgenerator -v
Qt Help Generator version 1.0 (Qt 5.9.5)

Could grab the Qt version number with sed as a quick solution.

Rik <rik5>
Project Administrator
Sun 30 Dec 2018 04:38:49 AM UTC, comment #40: 

Mike's suggestion in comment #35 would work on macOS.

Ben Abbott <bpabbott>
Project Member
Wed 26 Dec 2018 12:29:00 AM UTC, comment #39: 

I forgot to mention that QT_CPPFLAGS and QT_LDFLAGS should also be included in CPPFLAGS and LDFLAGS. This is because we haven't bothered to consistently include QT_CPPFLAGS and QT_LDFLAGS when compiling Qt related routines.

LDFLAGS="$LDFLAGS $QT_LDFLAGS"
CPPFLAGS="$CPPFLAGS $QT_CPPFLAGS"

Ben Abbott <bpabbott>
Project Member
Tue 25 Dec 2018 01:53:40 AM UTC, comment #38: 

I've successfully built octave on macOS using Qt 5.12.0.

I had to define QT_CPPFLAGS, and QT_LDFLAGS (not used/needed for Qt 5.11.2)

brew switch qt5 5.12.0
QCOLLECTIONGENERATOR=qhelpgenerator
export QCOLLECTIONGENERATOR
QT_CPPFLAGS="-I/usr/local/opt/qt/include"
export QT_CPPFLAGS
QT_LDFLAGS="-F/usr/local/opt/qt/lib"
export QT_LDFLAGS

I also included the definitions for QT_CPPFLAGS, and QT_LDFLAGS in CPPFLAGS and LDFLAGS. This last part was necessary to ensure the Qt include and libs were always available where Qt needed them. For example, the test for QAbstractItemModel::beginResetModel which was failing during configure.

Ben Abbott <bpabbott>
Project Member
Mon 24 Dec 2018 09:58:19 AM UTC, comment #37: 

I'm on macOS. With qt 5.11.2 the Qt configure process succeeds.

configure:72939: checking for QAbstractItemModel::beginResetModel in <QAbstractItemModel>
configure:72994: g++ -std=gnu++11 -c -fPIC -g -O2 -D_THREAD_SAFE -pthread  -I/usr/local/Cellar/qt/5.11.2/include/QtNetwork -I/usr/local/Cellar/qt/5.11.2/include -I/usr/local/Cellar/qt/5.11.2/include/QtPrintSupport -I/usr/local/Cellar/qt/5.11.2/include -I/usr/local/Cellar/qt/5.11.2/include/QtHelp -I/usr/local/Cellar/qt/5.11.2/include -I/usr/local/Cellar/qt/5.11.2/include/QtWidgets -I/usr/local/Cellar/qt/5.11.2/include -I/usr/local/Cellar/qt/5.11.2/include/QtGui -I/usr/local/Cellar/qt/5.11.2/include -I/usr/local/Cellar/qt/5.11.2/include/QtSql -I/usr/local/Cellar/qt/5.11.2/include -I/usr/local/Cellar/qt/5.11.2/include/QtXml -I/usr/local/Cellar/qt/5.11.2/include -I/usr/local/Cellar/qt/5.11.2/include/QtCore -I/usr/local/Cellar/qt/5.11.2/include -fPIC  -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/openssl/include -I/usr/local/opt/gettext/include -I/usr/local/opt/icu4c/include -I/usr/local/opt/sundials27/include -I/usr/local/opt/zlib/include conftest.cpp >&5
configure:72994: $? = 0
configure:73010: result: yes

With qt 5.12.0 the Qt configure process fails. This may or may not be unique to macOS.

configure:72939: checking for QAbstractItemModel::beginResetModel in <QAbstractItemModel>
configure:72994: g++ -std=gnu++11 -c -fPIC -g -O2 -D_THREAD_SAFE -pthread  -I/usr/local/Cellar/qt/5.12.0/lib/QtNetwork.framework/Headers -I/usr/local/Cellar/qt/5.12.0/lib/QtPrintSupport.framework/Headers -I/usr/local/Cellar/qt/5.12.0/lib/QtHelp.framework/Headers -I/usr/local/Cellar/qt/5.12.0/lib/QtWidgets.framework/Headers -I/usr/local/Cellar/qt/5.12.0/lib/QtGui.framework/Headers -I/usr/local/Cellar/qt/5.12.0/lib/QtSql.framework/Headers -I/usr/local/Cellar/qt/5.12.0/lib/QtXml.framework/Headers -I/usr/local/Cellar/qt/5.12.0/lib/QtCore.framework/Headers -fPIC  -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/openssl/include -I/usr/local/opt/gettext/include -I/usr/local/opt/icu4c/include -I/usr/local/opt/sundials27/include -I/usr/local/opt/zlib/include conftest.cpp >&5
In file included from conftest.cpp:507:
In file included from /usr/local/Cellar/qt/5.12.0/lib/QtCore.framework/Headers/QAbstractItemModel:1:
/usr/local/Cellar/qt/5.12.0/lib/QtCore.framework/Headers/qabstractitemmodel.h:43:10: fatal error: 'QtCore/qvariant.h' file not found
#include <QtCore/qvariant.h>
         ^~~~~~~~~~~~~~~~~~~
1 error generated.

For each, the include files are where they belong, and in equivalent locations. However, the configure process produces include entries that drill down into the frameworks on qt5.11 differently than on qt5.12.

For 5.11.2, the include files for QtCore are in each location below (sym-linkded).

/usr/local/Cellar/qt/5.11.2/lib/QtCore.framework/Headers/qvariant.h
/usr/local/Cellar/qt/5.11.2/include/QtCore/qvariant.h

For 5.12.0, the include files for QtCore are in each location below (sym-linkded).

/usr/local/Cellar/qt/5.12.0/lib/QtCore.framework/Headers/qvariant.h
/usr/local/Cellar/qt/5.12.0/include/QtCore/qvariant.h

For 5.11.2, the include entry is

-I/usr/local/Cellar/qt/5.11.2/include/QtCore

my configure includes a reference to the Qt frameworks.

LDFLAGS="$LDFLAGS -F/usr/local/opt/qt/lib"

For 5.12.0, the include entry is

-I/usr/local/Cellar/qt/5.12.0/lib/QtCore.framework/Headers

I've tried using a reference to the frameworks.

LDFLAGS="$LDFLAGS -F/usr/local/opt/qt/lib"

Also tried using a reference to the libs.

LDFLAGS="$LDFLAGS -L/usr/local/opt/qt/lib"

Ben Abbott <bpabbott>
Project Member
Mon 24 Dec 2018 05:41:12 AM UTC, comment #36: 

On macOS I added the following to my configure environment

QCOLLECTIONGENERATOR=qhelpgenerator
export QCOLLECTIONGENERATOR
QCOLLECTIONGENERATOR_QTVER=qhelpgenerator
export QCOLLECTIONGENERATOR_QTVER

However, I encountered the warning below.

configure: WARNING: QAbstractItemModel::beginResetModel not found; disabling Qt GUI

I have no problem with qt 5.11.2

Ben Abbott <bpabbott>
Project Member
Sun 16 Dec 2018 04:55:27 PM UTC, comment #35: 

Right. The current build uses the qcollectiongenerator tool to build the compressed help that is used in the Octave GUI itself. It also uses the qhelpgenerator tool in Doxyfile to build a compressed help format of the API docs with the optional 'make doxyhtml' target.

With Qt 5.12 the qhelpgenerator tool will serve both of those purposes.

Maybe we can create a small simple input file in the configure script that we can feed to qhelpgenerator to see if it can process it or not. If not, we need qcollectiongenerator. If yes, then we can use qhelpgenerator.

Mike Miller <mtmiller>
Project Administrator
Sun 16 Dec 2018 09:14:57 AM UTC, comment #34: 

> I thought the problem was that qcollectiongenerator does not exist on Qt 5.12 and above.


Correct.

If I understood you correctly you want to check only for existance of the scripts. Right now you check for both scripts qcollectiongenerator and qhelpgenerator, and I suppose there is a reason for doing so. I suppose you run qhelpgenerator somewhere in the build process for generation doxygen documentation. If this is not the case, the check for qhelpgenerator would have been wrong or at least superfluous before this bug report.

Stefan Husmann <haawda>
Sat 15 Dec 2018 10:25:45 PM UTC, comment #33: 

I thought the problem was that qcollectiongenerator does not exist on Qt 5.12 and above.  Is it installing both qcollectiongenerator and qhelpgenerator but only one of them works for our purposes?

Why do we need to check for qhelpgenerator if we have found a working copy of qcollectiongenerator (regardless of version) on the system?

Rik <rik5>
Project Administrator
Sat 15 Dec 2018 09:29:20 PM UTC, comment #32: 

You will need to check for qhelpgenerator also if the check for qcollectiongenerator succeeds, but otherwise, yes this might work.

Stefan Husmann <haawda>
Sat 15 Dec 2018 09:18:34 PM UTC, comment #31: 

Isn't it enough to reverse the testing order and check for qcollectiongenerator first, which will be detected and selected on older systems, and then if that fails (because we might be at Qt5.12 or higher) check for qhelpgenerator?

Rik <rik5>
Project Administrator
Sat 15 Dec 2018 06:05:01 PM UTC, comment #30: 

Rik - the main problem I see is that older Qt systems have both tools qcollectiongenerator and qhelpgenerator, and Octave correctly detects each of them by name alone. Now with Qt 5.12 and later it needs to somehow know that qhelpgenerator provides both roles. If we simply check for qhelpgenerator, the build may break with older versions of Qt.

Mike Miller <mtmiller>
Project Administrator
Sat 15 Dec 2018 05:59:06 PM UTC, comment #29: 

The test for qcollection generator is in m4/acinclude.m4

    AC_CHECK_TOOLS(QTCHOOSER, [qtchooser])

    OCTAVE_CHECK_QT_TOOL([moc])
    OCTAVE_CHECK_QT_TOOL([uic])
    OCTAVE_CHECK_QT_TOOL([rcc])
    OCTAVE_CHECK_QT_TOOL([lrelease])
    OCTAVE_CHECK_QT_TOOL([qcollectiongenerator])
    OCTAVE_CHECK_QT_TOOL([qhelpgenerator])

It seems like one possibility is to expand OCTAVE_CHECK_QT_TOOL macro to accept a list of possibilities which it would check and accept the first one found.  This is similar to how existing Autoconf macros work.

Possibility number two is to check for qhelpgenerator first, and if it is not found, check for qcollectiongenerator.  We should not condition checks on the version number of Qt, only on what is available in the system.

Changing the Severity to Important.  This should be fixed before the 5.0 release.

Rik <rik5>
Project Administrator
Sat 15 Dec 2018 01:56:17 AM UTC, comment #28: 

The configure varable you suggested works for me, and now the eps files, e.g. plot.eps plot3.eps and so on, are created.

AFAICS the Makefile.am only distincts between Qt's major versions, and now needs to distinct between major version 5 and 4, and if it is 5 check for minor version <12 and >=12, and in the latter case set QCOLLECTIONGENERATOR=QTHELPGENERATOR. I am not very firm in m4 and do not know how the syntax should be here.

Btw. running qhelpgenerator without argument on the command line gives out

Missing input file name.


Usage:

qhelpgenerator <file> [options]

  -o <output-file>       Generates a Qt compressed help
                         called <output-file> (*.qch) for the
                         Qt help project <file> (*.qhp).
                         Generates a Qt help collection
                         called <output-file> (*.qhc) for the
                         Qt help collection project <file>(*.qhcp).
                         If this option is not specified
                         a default name will be used
                         (*.qch for *.qhp and *.qhc for *.qhcp).
  -c                     Checks whether all links in HTML files
                         point to files in this help project.
  -s                     Suppresses status messages.
  -v                     Displays the version of
                         qhelpgenerator.

Stefan Husmann <haawda>
Sat 15 Dec 2018 01:16:37 AM UTC, comment #27: 

According to the docs the new tool is compatible with qcollectiongenerator, the page https://doc.qt.io/qt-5/qthelp-framework.html shows this example

> qhelpgenerator mycollection.qhcp -o mycollection.qhc


So it should be possible for you to build by setting QCOLLECTIONGENERATOR to qhelpgenerator-qt5.

If you can confirm that, can you also help update the configuration logic to work with this change? Is there a way for configure to detect the difference between the two cases "this system needs qcollectiongenerator but it's missing" and "this system should use qhelpgenerator instead of qcollectiongenerator"?

Mike Miller <mtmiller>
Project Administrator
Sat 15 Dec 2018 01:05:09 AM UTC, comment #26: 

Thanks for figuring that out. This looks like something we definitely want to fix for Octave 5, since Qt 5.12 is out now.

Is the command line of the new qhelpgenerator compatible with the old qcollectiongenerator tool? Can you try configuring with

./configure QCOLLECTIONGENERATOR=qhelpgenerator-qt5 …

Mike Miller <mtmiller>
Project Administrator
Sat 15 Dec 2018 12:49:11 AM UTC, comment #25: 

I think I found the culprit. In qt5-tools version 5.12 the Qt-people merged the tool qcollectiongenerator tool into the qhelpgenerator tool.

./configure checks for both tools and if qcollectiongenerator is missing the configure process believes that qt is not correctly installed and refuses to use it.

The compressed buildlog is about 100k.

What I try now is to use the qcollectiongenerator tool from qt4, but this cannot be a good solution.

(file #45669)

Stefan Husmann <haawda>
Fri 14 Dec 2018 11:25:51 PM UTC, comment #24: 

Still no files attached.  How big is the log file when xz compressed?

Rik <rik5>
Project Administrator
Fri 14 Dec 2018 09:58:33 PM UTC, comment #23: 

oops, hopefully you have xz installed.

Stefan Husmann <haawda>
Fri 14 Dec 2018 08:19:10 PM UTC, comment #22: 

Please compress that log file and try again. The attachment size limit on Savannah is annoyingly low.

Mike Miller <mtmiller>
Project Administrator
Fri 14 Dec 2018 07:56:10 PM UTC, comment #21: 

Sorry for the late reply. Buildlog attached.

Stefan Husmann <haawda>
Thu 13 Dec 2018 05:32:43 PM UTC, comment #20: 

Okay, we're really getting somewhere now.  The problem is that the Qt toolkit for plotting was not built.

Try

make distclean

to wipe out any compiled files.  Also remove config.cache if it is present.

Then run configure and save the results in a file, for example

./configure --YOUR-OPTIONS | tee tstconfig.log

Take a look at the end of configure where it gives a summary of the build options.  It should say that it is building the Qt gui.  Upload the file tstconfig.log as well so we can take a look.  Probably a missing library dependency.

Rik <rik5>
Project Administrator
Thu 13 Dec 2018 08:18:29 AM UTC, comment #19: 

Obvioulsy another problem:

available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
}

Qt version is 5.12, and configure-option --with-qt=5 was given.

Stefan Husmann <haawda>
Wed 12 Dec 2018 11:17:02 PM UTC, comment #18: 

It's odd that the graphics toolkit is FLTK and not qt.  Can you set the toolkit to qt and plot anything?

available_graphics_toolkits
graphics_toolkit qt
plot (1:10, 'o-')
print tst.eps

Rik <rik5>
Project Administrator
Wed 12 Dec 2018 09:36:53 PM UTC, comment #17: 

graphics_toolkit ()
ans = fltk

Name                     : gl2ps
Version                  : 1.4.0-1

octave:2> graphics_toolkit gnuplot
octave:3> plot (1:10, "o-");
Couldn't exec expected X11 driver: /usr/bin/gnuplot_x11
Did you set environmental variable GNUPLOT_DRIVER_DIR?
Exec failed: No such file or directory
octave:4> Couldn't exec expected X11 driver: /usr/bin/gnuplot_x11
Did you set environmental variable GNUPLOT_DRIVER_DIR?
Exec failed: No such file or directory

Okay, this means my gnuplot is broken. gnuplot_x11 is under /usr/lib/gnuplot/5.3 and not in $PATH.

I installed a working gnuplot and ran
octave:3> print -color tstplot.eps
octave:4> print -color tstplot.svg

Strangly tstplot.eps was still not created, but tstplot.svg was!

Stefan Husmann <haawda>
Wed 12 Dec 2018 07:07:29 PM UTC, comment #16: 

Finally, a bit of progress.  What version of gl2ps are you using?

Also, just to confirm, what does

graphics_toolkit ()

report?

Also, try

graphics_toolkit gnuplot
plot (1:10, "o-");
print -color tstplot.eps

This should definitely produce an output.

If everything goes as expected then try printing to svg.

graphics_toolkit qt
plot (1:10, "o-");
print -color tstplot.svg

This involves a different code path through gl2ps.

Rik <rik5>
Project Administrator
Wed 12 Dec 2018 06:56:33 PM UTC, comment #15: 

This is what I did and whats happening:

cd into the build directory

#cd build
#./run-octave -f

a prompt opens

#plot (1:10, "o-");

a gui opens with a plot in it. I can open a "file->save" dialog and save to a file untitled.ofig.

print -color tstplot.eps

a short flickering in the gui happens. No file tstplot.eps anywhere.

Stefan Husmann <haawda>
Wed 12 Dec 2018 04:59:33 PM UTC, comment #14: 

Does the created Octave version actually produce plots?

From the build directory, try

./run-octave -f
plot (1:10, "o-");
print -color tstplot.eps

Rik <rik5>
Project Administrator
Tue 11 Dec 2018 07:46:07 AM UTC, comment #13: 

I tried, no change.

Stefan Husmann <haawda>
Mon 10 Dec 2018 09:34:14 PM UTC, comment #12: 

This does sound like a corruption of the build system, possibly brought on by running the build in parallel.

Could you try

make maintainer-clean
sh autogen.sh
./configure --WHATEVER-OPTIONS-YOU-USE
make -j1 V=1

Rik <rik5>
Project Administrator
Mon 10 Dec 2018 09:12:50 PM UTC, comment #11: 

No files plot.eps or plot3.eps. "make -j1 V=1" now ends in

interpreter/octave.texi
(/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/build-aux/tex
info.tex Loading texinfo [version 2018-09-21.20]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc, environments,
defuns, macros, cross references, insertions,
(/usr/local/texlive/2018/texmf-dist/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.4 <14 February 2011>
) localization, formatting, and turning on texinfo input format.)
(/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/build/../doc/
interpreter/macros.texi)
(/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/build/../doc/
interpreter/version-octave.texi)
(octave_logo.eps
)

Overfull \hbox (1.16216pt too wide) in paragraph at lines 104--105
 |
[1] [2] (./octave.toc [-1] [-2] [-3] [-4])
Runaway argument?
{Debug Mod
/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/build/../doc/i
nterpreter/octave.texi:139: File ended while scanning use of @numsecentry.
<inserted text>
                @par
<to be read again>
                   @vfill
@contents ...feof 1 @else @readtocfile @fi @vfill
                                                  @eject @contentsalignmacro...
l.139 @contents

?

Stefan Husmann <haawda>
Mon 10 Dec 2018 08:16:13 PM UTC, comment #10: 

Could you attach plot.eps (if it is there) and also plot3.eps
(should be in the same directory)?

After that delete plot.eps (or move it somewhere) and try
to re-run "make -j1 V=1"

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Dec 2018 07:59:38 PM UTC, comment #9: 

Now with make -j1 V=1 the compilation stops.

(/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/build/doc/int
erpreter/plot.texi Chapter 15 [308]
(plot.eps
/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/build/doc/inte
rpreter/plot.texi:105: Could not open file plot.eps, ignoring it.
@epsfgetbb ...Could not open file #1, ignoring it}
                                                  @else {@chardef @other = 1...

@next #1->@epsfgetbb {#1}
                         @epsfsetgraph {#1}
@imagexxx ...ysize =#3@relax @fi @epsfbox {#1.eps}
                                                  @else @doxeteximage {#1}{#...

@image ...true @fi @else @imagexxx #1,,,,,@finish
                                                  @fi
<argument> @hfil @ignorespaces @image {plot,4in}
                                                @unskip @hfil
@centersub ...enalty @fi @line {@kern @leftskip #1
                                                  @kern @rightskip }
...
l.105 @center @image{plot,4in}

                             

?

Stefan Husmann <haawda>
Mon 10 Dec 2018 07:48:03 PM UTC, comment #8: 

I do get the same error on one of my workstation:

 GEN      doc/interpreter/splinefit6.png
  MAKEINFO ../doc/interpreter/octave.info
  TEXI2DVI doc/interpreter/octave.dvi
  MAKEINFO doc/interpreter/octave.html/.octave-html-stamp
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[2]: *** [Makefile:30623: doc/interpreter/octave.dvi] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/d2/home/dima/src/octave/gcc_def'
make[1]: *** [Makefile:26984: all-recursive] Error 1
make[1]: Leaving directory '/d2/home/dima/src/octave/gcc_def'

It did go away after I re-run make. This is a recurrent
problem with parallel doc build.

I can never reproduce this crash with  "make -j1"
and very seldom with "make V=1" The buildbots are running
"make V=1" perhaps this is the reason they are not crashing.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Dec 2018 07:35:22 PM UTC, comment #7: 

FYI -- Fedora also has texinfo 6.5 and the builds run fine:

http://buildbot.octave.org:8010/#/waterfall

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Dec 2018 07:07:02 PM UTC, comment #6: 

When I wrote the bugreport, it was revision 26184, now it is

[haawda@frege octave]$ hg tip
Änderung:        26188:6652de1fe896
Lesezeichen:     @
Marke:           tip
Nutzer:          Rik <rik@octave.org>
Datum:           Sun Dec 09 17:03:33 2018 -0800
Zusammenfassung: Hack margin of text objects to be measured in points, not pixels.

I will try with "make -j1 V=1", and report back.

Stefan Husmann <haawda>
Mon 10 Dec 2018 03:59:15 PM UTC, comment #5: 

What is the output of 'hg id' so we know exactly what changeset you are working with.

Also, try running this

make -j1 V=1

which will produce a more verbose list of the commands that Octave is running.  Upload the last part of this log that fails.

Rik <rik5>
Project Administrator
Mon 10 Dec 2018 08:25:02 AM UTC, comment #4: 

The build also fails for me with texinfo 6.5 with  the same message.

Stefan Husmann <haawda>
Mon 10 Dec 2018 06:56:24 AM UTC, comment #3: 

I'm running Texinfo 6.5.0 on Kubuntu 18.04.

Rik <rik5>
Project Administrator
Mon 10 Dec 2018 02:33:50 AM UTC, comment #2: 

I use a texinfo built from latest sources in git. I use texinfo-git-r8411.32abb3ac2a to be exact. Will try to downgrade to 6.5.

Stefan Husmann <haawda>
Mon 10 Dec 2018 12:59:43 AM UTC, comment #1: 

This sounds like a problem with the Texinfo tools you have installed.  What version are you using?

Rik <rik5>
Project Administrator
Sun 09 Dec 2018 11:50:48 AM UTC, original submission:  

I get this on Arch Linux when trying to build octave from hg-tip.

  TEXI2DVI doc/interpreter/octave.dvi
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[2]: *** [Makefile:30620: doc/interpreter/octave.dvi] Fehler 1
make[2]: Verzeichnis „/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/build“ wird verlassen
make[1]: *** [Makefile:26981: all-recursive] Fehler 1
make[1]: Verzeichnis „/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/build“ wird verlassen
make: *** [Makefile:10822: all] Fehler 2
==> FEHLER: Ein Fehler geschah in build().

Trying to run texi2dvi manually results in this:

This is `epsf.tex' v2.7.4 <14 February 2011>
) localization, formatting, and turning on texinfo input format.)
(/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/doc/interpret
er/macros.texi)
(/home/haawda/paketierung/meine_Pakete/octave-hg/src/octave-local/doc/interpret
er/version-octave.texi)
(octave_logo.eps
)

Overfull \hbox (1.16216pt too wide) in paragraph at lines 104--105
 |
[1] [2] [-1] [-2]
./octave.texi:930: I can't find file `preface.texi'.
@temp ->@input preface.texi

@includezzz ...and @input #1 }@expandafter }@temp
                                                  @popthisfilestack
l.930 @include preface.texi

(Press Enter to retry, or Control-D to exit)
Please type another input file name:
./octave.texi:930: Emergency stop.
@temp ->@input preface.texi

@includezzz ...and @input #1 }@expandafter }@temp
                                                  @popthisfilestack
l.930 @include preface.texi

Output written on octave.dvi (4 pages, 2488 bytes).
Transcript written on octave.log.
/usr/bin/texi2dvi: etex exited with bad status, quitting.

Indeed there is no file preface.texi, only preface.txi.

Stefan Husmann <haawda>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #45669:  buildlog.txt.xz added by haawda (107KiB - application/x-xz)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by albertjin (Posted a comment)
  • -email is unavailable- added by apjanke (Added Andrew to Notification list)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by haawda (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-26 apjanke Carbon-Copy- => Added floss@apjanke.net
    2018-12-15 rik5 Severity3 - Normal => 4 - Important
        StatusNeed Info => Confirmed
    2018-12-15 mtmiller StatusWorks For Me => Need Info
        SummaryQt toolkit not being built => build: fails to work with Qt 5.12, qcollectiongenerator no longer exists
    2018-12-15 haawda Attached File- => Added buildlog.txt.xz, #45669
    2018-12-13 rik5 CategoryDocumentation => Configuration and Build System
        SummarySomething in the conversion from preface.txi to preface.texi went wrong. => Qt toolkit not being built
    2018-12-10 rik5 StatusNone => Works For Me

    Back to the top


    Powered by Savane 3.5