bugGNU Octave - Bugs: bug #50129, Incorrect Qt version chosen after...

 
 

bug #50129: Incorrect Qt version chosen after automatic updates to configure

Submitter:  Rik <rik5>
Submitted:  Mon 23 Jan 2017 11:14:34 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 24 Jan 2017 11:35:36 PM UTC, comment #12: 

On my system, qt5 is the default and I don't use any qt version options.  Without the patch, I see the -qt5 option when running configure the first time (with the cache) but not when running it again.

I'll push the change.  If it breaks something else let me know.

John W. Eaton <jwe>
Group administrator
Tue 24 Jan 2017 11:31:27 PM UTC, comment #11: 

Sorry to be late to the party.  jwe's patch also works for me I think it should be applied.

Rik <rik5>
Group administrator
Tue 24 Jan 2017 11:15:50 PM UTC, comment #10: 

jwe's patch works for me, the FLAGS all have the right -qt4 option after re-running config.status and the build is a success, so I assume the same would work in the other direction (when Qt 4 is the default but -qt5 is used).

Mike Miller <mtmiller>
Group Member
Tue 24 Jan 2017 10:53:15 PM UTC, comment #9: 

Thanks, I can reproduce this now. I think I had been running config.status --recheck, but not actually using it to regenerate the Makefile, or something. Now I can see that the values for moc, etc, are loaded from the cache and no FLAGS are appended.

I'll try with your patch now that I can actually get the error to happen.

Mike Miller <mtmiller>
Group Member
Tue 24 Jan 2017 10:40:43 PM UTC, comment #8: 

Mike, are you using "configure -C" to enable config.cache?  I do see the problem if I use the cache:


rm -f config.cache
configure -C   ## MOCFLAGS is set to -qt5 in Makefile
touch configure
make V=1 Makefile  ## ultimately runs "./config.status --recheck" and MOCFLAGS is empty in Makefile


note that


rm -f config.cache
configure -C   ## MOCFLAGS is set to -qt5 in Makefile
touch Makefile.in
make V=1 Makefile  ## ultimately runs "./config.status Makefile" and MOCFLAGS is empty in Makefile


It's the "--recheck" part (with the cache) that causes the trouble.  This happens because of the problem that I noted in comment #6 about using MOC as the cache variable.

John W. Eaton <jwe>
Group administrator
Tue 24 Jan 2017 10:05:03 PM UTC, comment #7: 

Hmm, I can't reproduce this either, working on a system where Qt 5 is the default but I am building with --with-qt=4. I either have to set PATH explicitly to use the /usr/lib/x86_64-linux-gnu/qt4/bin directory, or configure finds the moc-qt4 symlinks first, or it finds the qtchooser executable and does the right thing in the end anyway. If qtchooser is found, even if MOC and the rest of them are cached, configure still automatically appends the -qt4 option to all commands. If qtchooser is not installed, then how could this work? I am not seeing the case where it fails to append the necessary -qt4 or -qt5 option.

Mike Miller <mtmiller>
Group Member
Tue 24 Jan 2017 07:57:36 PM UTC, comment #6: 

Could you try the attached change instead?  I think the caching is screwed up because we use the variable MOC when checking for moc-qt$ver.  Since AC_CHECK_TOOL uses the cache, it finds the value for MOC from the cache and then skipping the check for qtchooser.

It may be that my solution can fail in some other ways, but it seems to work for me to get MOCFLAGS set again when running config.status --recheck

If this solution fails for you, then I guess I'd still like to understand why and see if I can duplicate the problem.

(file #39552)

John W. Eaton <jwe>
Group administrator
Tue 24 Jan 2017 01:34:32 AM UTC, comment #5: 

The attached patch works for me.  I don't know if it is the best, but it might be good enough.

(file #39545)

Rik <rik5>
Group administrator
Tue 24 Jan 2017 01:10:20 AM UTC, comment #4: 

Yes, I want to save the value for MOC and MOCFLAGS together.  I tried changing the line


AC_SUBST(MOCFLAGS)


to


AC_ARG_VAR(MOCFLAGS, [flags to pass to moc])


However, the problem still remains.  According to the documentation for AC_ARG_VAR


The value of variable when configure was launched is saved in the cache, including if it was not specified on the command line but via the environment. Indeed, while configure can notice the definition of CC in ‘./configure CC=bizarre-cc’, it is impossible to notice it in ‘CC=bizarre-cc ./configure’, which, unfortunately, is what most users do.

We emphasize that it is the initial value of variable which is saved, not that found during the execution of configure. Indeed, specifying ‘./configure FOO=foo’ and letting ‘./configure’ guess that FOO is foo can be two different things.


This is indeed what seems to be happening.  The initial value is "", and then it is calculated by this stanza in m4/acinclude.m4.


      if test -z "$MOC"; then
        AC_CHECK_TOOLS(MOC, [moc])
        if test -n "$QTCHOOSER"; then
          MOCFLAGS="-qt$qt_version"
        fi
      fi


The cached value is always "", rather than the calculated value, which doesn't wark.  I'm trying something with AC_CACHE_CHECK right now to see if that works.

Rik <rik5>
Group administrator
Mon 23 Jan 2017 11:52:53 PM UTC, comment #3: 

Ok, I think you are saying that if the MOC variable is cached, then the MOCFLAGS variable must also be cached, and I agree that is probably what is going on here.

Compilers and compiler flags are typically saved with AC_ARG_VAR, for example CC and CFLAGS, CXX and CXXFLAGS, so they are either remembered or not together, while we have LRELEASE, MOC, RCC, and UIC saved as cached variables explicitly, but not the corresponding FLAGS variables. Yes we should either save or not save both sets of variables in the same way.

Mike Miller <mtmiller>
Group Member
Mon 23 Jan 2017 11:45:34 PM UTC, comment #2: 

I don't think caching the variables will help in this case, since saving the cache to a file is always optional, but declaring them as AC_ARG_VAR would force them to be saved in the command line arguments passed to configure when it is re-run. It's probably the caching of something else that is causing the appropriate test to be bypassed so that the right options are not calculated. I would take a look at what commands are used to determine whether the -qt4 or -qt5 options are needed, and whether they are bypassed in some cases while the options themselves are not saved.

This isn't a problem on my system because Qt 5 is the default, but maybe forcing a Qt 4 build would trigger this for me.

Mike Miller <mtmiller>
Group Member
Mon 23 Jan 2017 11:24:44 PM UTC, comment #1: 

Further information.  This is the series of commands that get run when the Autotools system discovers that the build system itself is out of date.


CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/rik/wip/Projects_Mine/octave-dev/build-aux/missing aclocal-1.15 -I m4
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/rik/wip/Projects_Mine/octave-dev/build-aux/missing autoconf
 cd . && /bin/bash /home/rik/wip/Projects_Mine/octave-dev/build-aux/missing automake-1.15 --foreign
/bin/bash ./config.status --recheck
running CONFIG_SHELL=/bin/bash /bin/bash ./configure --prefix=/home/rik/local --disable-hg-id -C CFLAGS=-O2 -pipe CXXFLAGS=-O2 -pipe FFLAGS=-O2 -pipe --no-create --no-recursion
configure: loading cache config.cache


And the problem that results is that the resulting Makefile does not have the varibale MOCFLAGS set to "-qt5".  It is empty, along with UICFLAGS and RCCFLAGS.

Maybe Octave needs to cache these configure variables?

Rik <rik5>
Group administrator
Mon 23 Jan 2017 11:14:34 PM UTC, original submission:  

This is a complicated issue, which I can work around, but it does indicate a problem with the build system on the development branch.

Recently there was a series of whitespace changes to the entire codebase to eliminate trailing newlines at the end of files.  After hg update, I ran make which proceeded to re-run configure and then do the build.  However, the build failed as shown below.


libtool: compile:  g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I/usr/include/freetype2 -I/usr/include/freetype2 -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 -I./libgui/qterminal/libqterminal -Ilibgui/src -I./libgui/src -I./libgui/src/m-editor -I./libgui/src/qtinfo -I./libgui/graphics -I./liboctave/cruft/misc -I./liboctave/array -Iliboctave/numeric -I./liboctave/numeric -Iliboctave/operators -I./liboctave/operators -I./liboctave/system -I./liboctave/util -Ilibinterp -I./libinterp -Ilibinterp/parse-tree -I./libinterp/parse-tree -Ilibinterp/corefcn -I./libinterp/corefcn -I./libinterp/octave-value -I./liboctave/wrappers -fPIC -pthread -fopenmp -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -O2 -pipe -MT libgui/src/m-editor/libgui_src_libgui_src_la-moc-file-editor-interface.lo -MD -MP -MF libgui/src/m-editor/.deps/libgui_src_libgui_src_la-moc-file-editor-interface.Tpo -c libgui/src/m-editor/moc-file-editor-interface.cc  -fPIC -DPIC -o libgui/src/m-editor/.libs/libgui_src_libgui_src_la-moc-file-editor-interface.o
libgui/src/m-editor/moc-file-editor-interface.cc:16:2: error: #error "This file was generated using the moc from 4.8.6. It"
 #error "This file was generated using the moc from 4.8.6. It"
  ^
libgui/src/m-editor/moc-file-editor-interface.cc:17:2: error: #error "cannot be used with the include files from this version of Qt."
 #error "cannot be used with the include files from this version of Qt."
  ^
libgui/src/m-editor/moc-file-editor-interface.cc:18:2: error: #error "(The moc has changed too much.)"
 #error "(The moc has changed too much.)"


I have two versions of Qt development libraries installed on the computer, Qt4 and Qt5.  If I don't specify a version to Octave's configure script then it defaults to Qt5.  That's fine, and if I look at the synopsys at the end of configure I see:


  Qt CPPFLAGS:                   -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5
  Qt LDFLAGS:
  Qt libraries:                  -lQt5Network -lQt5OpenGL -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Core  -lqt5scintilla2
  Qt moc:                        moc -qt5
  Qt uic:                        uic -qt5
  Qt rcc:                        rcc -qt5
  Qt lrelease:                   lrelease -qt5


As one can see, it has chose qt5 correctly, and is adding the -qt5 option to the 'moc' command.

However, when the build system automatically re-runs configure, I am getting a different result. 


  Qt CPPFLAGS:                   -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5
  Qt LDFLAGS:
  Qt libraries:                  -lQt5Network -lQt5OpenGL -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Core  -lqt5scintilla2
  Qt moc:                        moc
  Qt uic:                        uic
  Qt rcc:                        rcc
  Qt lrelease:                   lrelease


As you can see, it is no longer using the -qt5 option.  Thus, when it runs I pick up the version for Qt4.8.6 and I get the error.

This may be because of caching.  This is the result during the re-run of configure.


checking Qt version 5... checking for QT... yes
checking for moc-qt5... (cached) moc
checking for uic-qt5... (cached) uic
checking for rcc-qt5... (cached) rcc
checking for lrelease-qt5... (cached) lrelease


And this is the result of a configure run after 'make distclean'


checking Qt version 5... checking for QT... yes
checking for moc-qt5... no
checking for uic-qt5... no
checking for rcc-qt5... no
checking for lrelease-qt5... no
checking for qtchooser... qtchooser
checking for moc... moc
checking for uic... uic
checking for rcc... rcc
checking for lrelease... lrelease


There are more things that get tested, including qtchooser.


Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #39552:  diffs.txt added by jwe (1KiB - text/plain)
file #39545:  acinclude.diffs added by rik5 (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-01-25 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2017-01-24 jwe Attached File- Added diffs.txt, #39552
    2017-01-24 rik5 Attached File- Added acinclude.diffs, #39545
        StatusNone Patch Submitted

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code