Am 09.07.2015 um 03:21 schrieb Jerry <lancebo...@qwest.net>: > > On Jul 8, 2015, at 4:48 PM, Jerry <lancebo...@qwest.net> wrote: > >> >> On Jul 8, 2015, at 9:09 AM, Stephan Witt <st.w...@gmx.net> wrote: >> >>> Am 08.07.2015 um 13:08 schrieb Jerry <lancebo...@qwest.net>: >>> >>>> >>>> On Jul 8, 2015, at 3:32 AM, Stephan Witt <st.w...@gmx.net> wrote: >>>> >>>>> Am 08.07.2015 um 12:06 schrieb Jerry <lancebo...@qwest.net>: >>>>> >>>>>> >>>>>> On Jul 7, 2015, at 10:54 PM, Stephan Witt <st.w...@gmx.net> wrote: >>>>>> >>>>>>> Am 08.07.2015 um 01:20 schrieb Jerry <lancebo...@qwest.net>: >>>>>>> >>>>>>> This means you didn't add --enable-qt5=yes - but this is only useful >>>>>>> for systems >>>>>>> with Qt4 and Qt5 installed side by side (like Linux distros typically >>>>>>> do) and >>>>>>> with different names for QtCore et al. >>>>>>> >>>>>>> The problem with Qt detection here is the complete ignorance of the >>>>>>> --with-qt-dir >>>>>>> command line option given to configure. I don't know how this should >>>>>>> work intentionally >>>>>>> but your Qt4 MacPorts Qt-version wins because of the position of >>>>>>> /opt/local/bin in >>>>>>> PATH and configure trying to detect Qt with pkg-config with without >>>>>>> using the value >>>>>>> given by --with-qt-dir. >>>>>>> >>>>>>> Why this doesn't work at the end I don't know - I don't have the >>>>>>> MacPorts Qt package. >>>>>>> >>>>>>> Regards, Stephan >>>>>>> >>>>>>> PS. I fear, you'll have a long way to go if you want to solve all >>>>>>> issues coming along >>>>>>> this route. In case you want to ditch the MacPort route and go for Qt5 >>>>>>> - I tried it with >>>>>>> Qt5.5.0 now and this is broken too. They've fixed the issue with RPATH >>>>>>> dyld at runtime >>>>>>> lookup of the Qt-frameworks and now the LyX binary aborts on startup >>>>>>> because of this. >>>>>>> I have to get a working environment with Qt5.5.0 myself first before I >>>>>>> can tell you >>>>>>> the recipe for building LyX this way. >>>>>> >>>>>> So I gather that somehow configure is ignoring --with-qt-dir and >>>>>> defaulting to the path precedence. Would it help if I prepended >>>>>> /Applications/Words/LyXOuterFolder/git/qt/Qt_Creator.app/Contents/Frameworks >>>>>> to the front of PATH so that it finds Qt5 first? >>>>> >>>>> No, I don't think so. IMHO, the problem is in configure using the >>>>> /opt/local/bin/pkg-config utility first and trying the given qt-dir >>>>> as a fallback only. >>>>> >>>>>> I'm not sure I follow everything in your PS. I can use MacPorts to >>>>>> install qt5-mac 5.4.2 (5.5 is not yet available at MacPorts). Is that >>>>>> worth a try while also adding --enable-qt5=yes? (I need to keep MacPorts >>>>>> Qt4 around for other stuff, I assume.) >>>>> >>>>> This one I cannot answer. I'd try it probably. >>>>> >>>>> But I fear this conflicts with the MacPorts way of doing things. >>>>> I'd guess you have to choose the active port of Qt after having >>>>> both versions installed and MacPorts will create some links to >>>>> the active version for you. I don't know. >>>>> >>>>> Regards, Stephan >>>> >>>> Hmmm.... It looks like there are activate and deactivate commands for >>>> MacPorts. I don't know how they handle things if one programs wants one >>>> version and another program wants another version. Seems like this >>>> wouldn't be allowed in general but I might get away with playing around >>>> for a bit. >>> >>> I've put a change in to add the necessary -rpath options to the linker >>> command line. >>> These are required to use the self-made Qt5.5.x and probably for the >>> frameworks built by Digia. >>> Look at git commit 6e9bd23a1f1888b2022335b2d05a3f770ada935a >>> >>> I'm not sure if this is enough to use the Digia frameworks. >>> >>> Regards, Stephan >>> >> I tried building with your changes. Using the same script as before, errors >> occur as such: >> >> CXXLD lyx >> Undefined symbols for architecture x86_64: >> "decltype(*(std::__1::forward<lyx::frontend::GuiWorkArea*&>(fp0)).*fp(std::__1::forward<>(fp1))) >> std::__1::__invoke<void (lyx::frontend::GuiWorkArea::*&)(), >> lyx::frontend::GuiWorkArea*&, void>(void >> (lyx::frontend::GuiWorkArea::*&&&)(), lyx::frontend::GuiWorkArea*&&&)", >> referenced from: >> >> boost::detail::function::void_function_obj_invoker0<std::__1::__bind<void >> (lyx::frontend::GuiWorkArea::*)(), lyx::frontend::GuiWorkArea*>, >> void>::invoke(boost::detail::function::function_buffer&) in >> liblyxqt4.a(GuiWorkArea.o) >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> make[4]: *** [lyx] Error 1 >> make[3]: *** [install-recursive] Error 1 >> make[2]: *** [install] Error 2 >> make[1]: *** [install-recursive] Error 1 >> make: *** [install-strip] Error 2 >> >> I added --enable-qt5=yes to the configure line and got this: >> >> checking for QT_CORE... checking for QT_FRONTEND... checking for X... >> disabled >> checking for Qt library name... failed >> configure: error: cannot compile a simple Qt executable. Check you have the >> right $QTDIR. >> make: *** No targets specified and no makefile found. Stop. >> make: *** No rule to make target `install-strip'. Stop. >> >> Jerry > > I tried to build again but (1) removed the --enable-qt5=yes argument
With it it's not working if the framework name is not e.g. QtCore5. > and (2) removed the path to the Qt5 frameworks, > --with-qt-dir="/Applications/Words/LyXOuterFolder/git/qt/Qt_Creator.app/Contents/Frameworks/", > thinking that the Qt4 things might be found in MacPorts. Yes, it's apparently not used by configure. > The result is the same as the previous attempt, summarized immediately above > in this post, beginning with the line, CXXLD lyx. I fear there is an incompatibility between the compiler or boost library used by MacPorts for building Qt and the tool chain LyX is using for build by configure. I never managed to build LyX with MacPorts components included. Stephan
