|
From: Daniel J S. <dan...@ie...> - 2017-08-31 21:45:17
|
I upgraded to Mint 18.2 here, and I'm going through all the usually system rebuilding... Why does configure report: checking for QT... yes configure: WARNING: The Qt terminal will use Qt5. Is it simply because Qt5 is considered experimental support at this stage? Also, when compiling I ran into a missing lrelease utility for Qt: c++ -g -O2 -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -fPIC -lcerf -o gnuplot_qt qtterminal/gnuplot_qt.o qtterminal/QtGnuplotWindow.o qtterminal/QtGnuplotApplication.o qtterminal/QtGnuplotWidget.o qtterminal/QtGnuplotScene.o qtterminal/QtGnuplotItems.o qtterminal/QtGnuplotEvent.o qtterminal/moc_QtGnuplotWindow.o qtterminal/moc_QtGnuplotApplication.o qtterminal/moc_QtGnuplotWidget.o qtterminal/moc_QtGnuplotScene.o qtterminal/moc_QtGnuplotEvent.o qtterminal/qrc_QtGnuplotResource.o -lQt5Network -lQt5Svg -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Core -ldl -lm -lcerf -lz -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lcairo -lglib-2.0 /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease /home/sebald/gnuplot/gnuplot/gnuplot/src/qtterminal/po/qtgnuplot_fr.ts -qm qtgnuplot_fr.qm /bin/bash: /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease: No such file or directory Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed make[4]: *** [qtgnuplot_fr.qm] Error 127 Should configure check for that lrelease file that is being included? It isn't too much trouble to find the package and install lrelease (qttools5-dev-tools), but that package isn't automatically installed with all the other Qt5 packages as a requirement. After installing qttools5-dev-tools, compilation continues with 29 translations for Qt. I then ran into this problem: make[2]: Entering directory '/usr/local/src/gnuplot/gnuplot/build1/docs' lua5.2 /home/sebald/gnuplot/gnuplot/gnuplot/term/lua/gnuplot-tikz.lua termhelp > gnuplot-tikz.help /bin/bash: lua5.2: command not found Makefile:979: recipe for target 'gnuplot-tikz.help' failed make[2]: *** [gnuplot-tikz.help] Error 127 which is of the same variety as the previous problem. I had to install lua5.2 package because it isn't a requirement for liblua5.2-dev package. Should configure check for the lua executable? sebald@ ~/gnuplot/gnuplot/gnuplot $ lua5.2 -v Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio Dan |
|
From: sfeam <sf...@us...> - 2017-09-01 00:38:21
|
On Thursday, 31 August 2017 16:05:48 Daniel J Sebald wrote: > I upgraded to Mint 18.2 here, and I'm going through all the usually > system rebuilding... > > Why does configure report: > > checking for QT... yes > configure: WARNING: The Qt terminal will use Qt5. > > Is it simply because Qt5 is considered experimental support at this stage? Just because the macro autotools provides to write something non-fatal during configuration is AC_MSG_WARN. You'd think they would provide something blander like AC_MSG_JUST_IN_CASE_YOU_CARE, but no. WARN is better than the alternatives ERROR or FAILURE. > Also, when compiling I ran into a missing lrelease utility for Qt: > > /bin/bash: /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease: No such file or > directory > Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed > make[4]: *** [qtgnuplot_fr.qm] Error 127 > > Should configure check for that lrelease file that is being included? Sure. But I don't know how to do that. lrelease is not a library, so the library test macros don't help. > It isn't too much trouble to find the package and install lrelease > (qttools5-dev-tools), but that package isn't automatically installed > with all the other Qt5 packages as a requirement. That seems more like a failure of the mint package dependencies than something gnuplot's configure script is responsible for. FWIW on my machines lrelease does not come in a separate *-dev-* package. It's in qttools5 proper. > After installing > qttools5-dev-tools, compilation continues with 29 translations for Qt. > > I then ran into this problem: > > make[2]: Entering directory '/usr/local/src/gnuplot/gnuplot/build1/docs' > lua5.2 /home/sebald/gnuplot/gnuplot/gnuplot/term/lua/gnuplot-tikz.lua > termhelp > gnuplot-tikz.help > /bin/bash: lua5.2: command not found > Makefile:979: recipe for target 'gnuplot-tikz.help' failed > make[2]: *** [gnuplot-tikz.help] Error 127 > > which is of the same variety as the previous problem. I had to install > lua5.2 package because it isn't a requirement for liblua5.2-dev package. > Should configure check for the lua executable? The configure script uses pkg-config to check for lua. It checks for "lua", and if that fails it checks for "lua5.1", "lua5.2", "lua5.3". So again it sounds like mint weirdness. If pkg-config is reporting that you have lua installed but really you do not, I would consider that a system configuration error. But also it's weird that bash is trying to run explicitly lua5.2. Normally it just runs "lua" and that invokes the current installed version whatever it is. Can you pin down what script this is, exactly? I don't see any such script in the gnuplot source. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2017-09-01 04:10:20
Attachments:
gnuplot-qt_and_lua_build_cleanup-djs2017aug31.patch
|
I'm attaching a patch file with some mods that work for me. Should I open a bug report and post the diff file there? That will allow more organized development. More comments below... On 08/31/2017 07:36 PM, sfeam wrote: > On Thursday, 31 August 2017 16:05:48 Daniel J Sebald wrote: >> I upgraded to Mint 18.2 here, and I'm going through all the usually >> system rebuilding... >> >> Why does configure report: >> >> checking for QT... yes >> configure: WARNING: The Qt terminal will use Qt5. >> >> Is it simply because Qt5 is considered experimental support at this stage? > > Just because the macro autotools provides to write something non-fatal > during configuration is AC_MSG_WARN. You'd think they would provide > something blander like AC_MSG_JUST_IN_CASE_YOU_CARE, but no. > WARN is better than the alternatives ERROR or FAILURE. There is AC_MSG_RESULT, which is used a few other places in the configure.ac file. If you want to add "checking " to the front to match all the other lines that's fine. >> Also, when compiling I ran into a missing lrelease utility for Qt: >> >> /bin/bash: /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease: No such file or >> directory >> Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed >> make[4]: *** [qtgnuplot_fr.qm] Error 127 >> >> Should configure check for that lrelease file that is being included? > > Sure. But I don't know how to do that. lrelease is not a library, so the > library test macros don't help. Asking for the version: sebald@ ~ $ lrelease -version lrelease version 5.5.1 should return with 0 if lrelease is present, otherwise return non-zero. It should be possible to run the command from configure and check the result. >> It isn't too much trouble to find the package and install lrelease >> (qttools5-dev-tools), but that package isn't automatically installed >> with all the other Qt5 packages as a requirement. > > That seems more like a failure of the mint package dependencies than > something gnuplot's configure script is responsible for. > FWIW on my machines lrelease does not come in a separate *-dev-* > package. It's in qttools5 proper. Yes, it does seem that way. Maybe the developers will catch this eventually. >> After installing >> qttools5-dev-tools, compilation continues with 29 translations for Qt. >> >> I then ran into this problem: >> >> make[2]: Entering directory '/usr/local/src/gnuplot/gnuplot/build1/docs' >> lua5.2 /home/sebald/gnuplot/gnuplot/gnuplot/term/lua/gnuplot-tikz.lua >> termhelp > gnuplot-tikz.help >> /bin/bash: lua5.2: command not found >> Makefile:979: recipe for target 'gnuplot-tikz.help' failed >> make[2]: *** [gnuplot-tikz.help] Error 127 >> >> which is of the same variety as the previous problem. I had to install >> lua5.2 package because it isn't a requirement for liblua5.2-dev package. >> Should configure check for the lua executable? > > The configure script uses pkg-config to check for lua. > It checks for "lua", and if that fails it checks for "lua5.1", "lua5.2", "lua5.3". > So again it sounds like mint weirdness. If pkg-config is reporting that you > have lua installed but really you do not, I would consider that a system > configuration error. > > But also it's weird that bash is trying to run explicitly lua5.2. > Normally it just runs "lua" and that invokes the current installed version > whatever it is. Can you pin down what script this is, exactly? I don't > see any such script in the gnuplot source. Ah, that's probably because these are two different things. The $PKG_CONFIG is checking for the associated package files in the directory where the pertinent library was built. That package is lua5.2. I assume this package construct is because there is some code compiled into gnuplot that interacts with lua libraries. But what was failing is the executable name, "lua"...which typically consists of a link to the (or some) package directory, e.g., lrwxrwxrwx 1 root root 33 Aug 31 15:50 /usr/bin/lua -> /etc/alternatives/lua-interpreter well, in this case there is an extra level of abstraction. I suppose the idea is that the library is used to construct something that can input to the external "lua" app. The configure.ac doesn't make any distinction between those. I've added a LUA_CMD=lua and changed $(LUA) to $(LUA_CMD) in a select few locations. As with lrelease, the LUA_CMD could be verified with sebald@ ~ $ lua -v Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio return 0 as opposed to -1. I'm just assuming it is present for now. Dan |