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 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. The result is the same as the previous attempt, summarized immediately above in this post, beginning with the line, CXXLD lyx. Jerry
