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
