Add a New Comment (Rich Markup)
( Jump to the original submission )
Would anyone like to try to convince the Qscintilla project to fix their mess?
It is a bit silly to depend on library names. It's also a bit silly that Qscintilla just dumps files into the Qt directories and doesn't provide any pkg-config metadata about itself. If you think that such a change needs to be made to properly detect and build with Qscintilla with homebrew, please file a new bug report with this information.
Yes exactly. Homebrew dropped qt4 support hence there was no need to rename libqscintilla to libqscintilla-qt5. I expected octave to choose the first library from the list "qscintilla2-qt5 qt5scintilla2 qscintilla2" and if it arrives at qt4-based qscintilla2 the build test should fail? It's a bit silly to depend on names of libraries... (I know it's not octave's fault)
I don't think so, that would be a very bad change. On Debian-based and Fedora-based distributions, libqscintilla2 is the version of the library built against Qt 4, and can easily be coinstalled alongside Qscintilla built for Qt 5. Checking for libqscintilla2 might find that library, and erroneously enable Qscintilla support, and either cause a build failure or a runtime failure when it turns out that two conflicting Qt versions have been built in together. Is homebrew installing Qscintilla as libqscintilla2 regardless of being built against Qt 4 or 5?
Dear Mike, can we add the default name "qscintilla2" to the list of qt5 candidates? "qscintilla2-qt5 qt5scintilla2" -> "qscintilla2-qt5 qt5scintilla2 qscintilla2" Sebastian
It works on Manjaro linux. I have qscintilla5 It wasn't. Saleh
Works for me (on Fedora 24). Dmitri.
I pushed a changeset that adds the ability to try linking with QScintilla over a set of possible names: http://hg.savannah.gnu.org/hgweb/octave/rev/f394436a4025 It works for me with both Qt 4 and 5, please test and let me know if it works on your system (or someone who was affected, if you weren't).
I'm attaching a diff file which is just meant to illustrate a way to identify the QScintilla library file name. I just wanted to see if I could identify the file first so printed out the info at the end of configure. This doesn't work through probably because I'm not supplying enough header files or libraries. Is a workable strategy though? I.e., first identify the name of the Qt4 and Qt5 scintilla library file names. Then later when the decision is made which Qt to use ("5 4" or the user's switch), one of these QT4LIBQSCINTILLA/QT5LIBQSCINTILLA variables could be used. (file #38204)
This problem was first identified here: https://savannah.gnu.org/bugs/?40252#comment30 and I don't see a new bug report for the issue so I'm creating one because a user has already run into this issue on Manjaro Linux. Basically, for Qt5 it appears that there is not a single way in which the QScintilla library file is named. So far there is either: libqt5scintilla2.so libqscintilla2-qt5.so but the Octave configure script has this name hard-coded as:
## Check for Qt libraries case "$qt_version" in 4) QT_MODULES="QtCore QtGui QtNetwork QtOpenGL" LIBQSCINTILLA=qscintilla2 ;; 5) QT_MODULES="Qt5Core Qt5Gui Qt5Network Qt5OpenGL Qt5PrintSupport" LIBQSCINTILLA=qt5scintilla2 ;; *) as_fn_error $? "Unrecognized Qt version $qt_version" "$LINENO" 5 ;; esac
Note this comment about assumption:
## Let's assume Qscintilla library is at the same location as ## other regular Qt libraries. QT_LIBS="$QT_LIBS -l$LIBQSCINTILLA"
is supposed to be a certainty. The documentation at the link below states "Installation As supplied QScintilla will be built as a shared library/DLL and installed in the same directories as the Qt libraries and include files.": http://pyqt.sourceforge.net/Docs/QScintilla2/ So there are at least a couple ways to go about this. 1) Expand the definition of $LIBQSCINTILLA to be as many files as user report, i.e., start with the list I gave above. Then loop through that list of possible files. It wouldn't be too much work to add a list 2) Drop this script
## Check for Qscintilla library which is used in the Qt GUI editor. { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether Qscintilla library is installed" >&5 $as_echo_n "checking whether Qscintilla library is installed... " >&6; } if ${octave_cv_lib_qscintilla+:} false; then : $as_echo_n "(cached) " >&6 else save_CPPFLAGS="$CPPFLAGS" save_CXXFLAGS="$CXXFLAGS" save_LDFLAGS="$LDFLAGS" save_LIBS="$LIBS" CPPFLAGS="$QT_CPPFLAGS $CXXPICFLAG $CPPFLAGS" CXXFLAGS="$CXXPICFLAG $CXXFLAGS" LDFLAGS="$QT_LDFLAGS $LDFLAGS" LIBS="$QT_LIBS -l$LIBQSCINTILLA" ac_ext=cpp ac_cpp='$CXXCPP $CPPFLAGS' ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5' ac_link='$CXX -o conftest$ac_exeext $CXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' ac_compiler_gnu=$ac_cv_cxx_compiler_gnu cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ #include <Qsci/qscilexersql.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { QsciLexerSQL sqlLexer(0); ; return 0; }
in exchange for some script that simply searches the identified Qt library directories...hmm, this might not work so well simply because of the fact there could be Qt4 files still about and searching for "scintilla" is a problem. We don't know where the '5' is going to appear so we are again back to searching for very specific patterns. 3) Can the AC_SEARCH_LIBS script: https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Libraries.html be used to search for a routine we know exists in Qt5 but not in Qt4?
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
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 project members can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 4 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11