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? 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.) Jerry
