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>: >>> >>>> >>>> On Jul 7, 2015, at 12:38 PM, Georg Baum <georg.b...@post.rwth-aachen.de> >>>> wrote: >>>> >>>>> Jean-Marc Lasgouttes wrote: >>>>> >>>>>> Le 07/07/2015 01:07, Jerry a écrit : >>>>>>> CXX CutAndPaste.o >>>>>>> CutAndPaste.cpp:390:15: error: call to 'next' is ambiguous >>>>>>> pars.insert(next(pars.begin(), pit), >>>>>>> ^~~~ >>>>>>> >>>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iterator:509:1: >>>>>>> note: >>>>>>> candidate function [with _ForwardIter = >>>>>>> std::__1::__list_iterator<lyx::Paragraph, void *>] >>>>>>> next(_ForwardIter __x, >>>>>>> ^ >>>>>>> ./support/lyxalgo.h:92:11: note: candidate function [with It = >>>>>>> std::__1::__list_iterator<lyx::Paragraph, void *>, Diff = long] >>>>>>> inline It next(It i, Diff n = 1) >>>>> >>>>> We had this error before. It probably means that your clang version >>>>> provides >>>>> a std::next from the C++11 standard even if no C++11 standard is >>>>> requested >>>>> on the command line. Since we do not try to detect ourselves anymore >>>>> whether >>>>> C++98 or C++11 is used, we will probably see this more and more in the >>>>> future, and at some point in time we'll need to set the compiler >>>>> commandline >>>>> option --std=C++98 if configure was not called with --enable-cxx11. >>>>> >>>>>> What happens if you add --enable-cxx1 to the configure command-line? >>>>> >>>>> This should mean of course --enable-cxx11. >>>>> >>>>> >>>>> Georg >>>>> >>>>> >>>>> PS: The config log file looks good at a first glance. clang and libc++ >>>>> are >>>>> correctly detected. >>>>> >>>> I added --enable-cxx11 to configure and removed the space--as discussed >>>> elsewhere in this thread--from the path to the Qt5 things. The compiler >>>> problems have gone away but now there appear to be problems linking Qt. >>>> Recall that the Qt version that I am attempting to reach is 5.5 downloaded >>>> from Qt's own web site. >>>> >>>> Here is my build script: >>>> >>>> >>>> >>>> #!/bin/bash >>>> >>>> # Create a build directory if one does not already exist. >>>> cd /Applications/Words/LyXOuterFolder/git >>>> mkdir -p build >>>> >>>> # Clean out any previous build products but leave the build directory (*). >>>> rm -rf /Applications/Words/LyXOuterFolder/git/build/* >>>> rm -rf /Applications/Words/LyXOuterFolder/git/Contents/ >>>> >>>> cd /Applications/Words/LyXOuterFolder/git/lyx/ >>>> ./autogen.sh >>>> >>>> # Move to build directory and run configure that is in lyx directory. >>>> cd /Applications/Words/LyXOuterFolder/git/build/ >>>> ../lyx/configure \ >>>> --with-version-suffix=-2.X \ >>>> --with-libiconv-prefix=/usr/lib \ >>>> --with-x=no \ >>>> --disable-stdlib-debug \ >>>> --enable-cxx11 \ >>>> --prefix=/Applications/Words/LyXOuterFolder/git \ >>>> --with-qt-dir="/Applications/Words/LyXOuterFolder/git/qt/Qt_Creator.app/Contents/Frameworks/" >>>> make >>>> make install-strip >>>> >>>> >>>> >>>> Here are the last few lines with errors. The linker might have found my >>>> Qt4 installation from MacPorts. I don't know if it is 32-bit or 64-bit or >>>> both. /opt/local/ is the MacPorts stuff. FWIW the referenced library is >>>> here: >>>> >>>> /Applications/Words/LyXOuterFolder/git/build/src/frontends/qt4/liblyxqt4.a >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> Attached is my config log. It contains the lines >>>> >>>> configure:2893: checking whether Qt5 is requested >>>> configure:2902: result: no >>> >>> 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. Jerry
