Re: Build questions for OS X
On Thursday 09 July 2015 21:39:22 Georg Baum wrote: > gcc does not do that yet (even in gcc 5.1 the default is C++98). That is supposed to change for the next version (6.1) to be released next year. And the change will be either to c++11 or to c++14 mode. And even Debian is already preparing for that change. :-) -- José Abílio
Re: Build questions for OS X
Am 09.07.2015 um 21:39 schrieb Georg Baum : > Jean-Marc Lasgouttes wrote: > >> On 09/07/2015 17:13, Jean-Marc Lasgouttes wrote: >>> From what I understand, the problem is only with libc++ (the clang >>> Standard library) and on this one setting std=c++98 does not change >>> anything. I just tried that with clang 3.6 and compilation fails. >>> >>> We should maybe make c++11 the default for new enough compilers. > > Yes. > >> Here is a reference: >> http://stackoverflow.com/questions/28027438/std-c-98-and-os-x-10-10/ >> >> And here is below the error I get. > > OK, so the summary is: > > - libc++ requires C++11 => we should enable C++11 automatically in configure > if libc++ is found. > > - New compilers might default to C++11 if no -std argument is given. If that > happens, then LyX will not compile anymore, because the #defines are set for > C++98. gcc does not do that yet (even in gcc 5.1 the default is C++98). > clang does a mixture according to http://clang.llvm.org/cxx_status.html: It > accepts some C++11 features even in C++98 mode. For windows targets it > defaults to C++11 (see http://clang.llvm.org/docs/UsersManual.html#cxx). > Therefore I think your suggestion to enable C++11 mode for newer compilers > is all we need to do. Just for the record: now I've tested the LyX build on my Mac OS X 10.10.3 with Xcode 6. This works on my system too. So, I've to working compilers: on 10.8.6 with Xcode 5.5.1 Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn) on 10.10.3 with Xcode 6 Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Stephan
Re: Build questions for OS X
Jean-Marc Lasgouttes wrote: > On 09/07/2015 17:13, Jean-Marc Lasgouttes wrote: >> From what I understand, the problem is only with libc++ (the clang >> Standard library) and on this one setting std=c++98 does not change >> anything. I just tried that with clang 3.6 and compilation fails. >> >> We should maybe make c++11 the default for new enough compilers. Yes. > Here is a reference: > http://stackoverflow.com/questions/28027438/std-c-98-and-os-x-10-10/ > > And here is below the error I get. OK, so the summary is: - libc++ requires C++11 => we should enable C++11 automatically in configure if libc++ is found. - New compilers might default to C++11 if no -std argument is given. If that happens, then LyX will not compile anymore, because the #defines are set for C++98. gcc does not do that yet (even in gcc 5.1 the default is C++98). clang does a mixture according to http://clang.llvm.org/cxx_status.html: It accepts some C++11 features even in C++98 mode. For windows targets it defaults to C++11 (see http://clang.llvm.org/docs/UsersManual.html#cxx). Therefore I think your suggestion to enable C++11 mode for newer compilers is all we need to do. Georg
Re: Build questions for OS X
On 09/07/2015 17:13, Jean-Marc Lasgouttes wrote: From what I understand, the problem is only with libc++ (the clang Standard library) and on this one setting std=c++98 does not change anything. I just tried that with clang 3.6 and compilation fails. We should maybe make c++11 the default for new enough compilers. Here is a reference: http://stackoverflow.com/questions/28027438/std-c-98-and-os-x-10-10/ And here is below the error I get. JMarc tanuki: ../master/configure --with-version-suffix=-master --without-included-boost CXX="clang++ -std=c++98 --stdlib=libc++" CXXFLAGS=-Wno-overloaded-virtual [...] Configuration Host type: x86_64-unknown-linux-gnu Special build flags: build=development warnings assertions stdlib-debug use-enchant C++ Compiler:clang++ -std=c++98 --stdlib=libc++ C++ Compiler flags: -Wall -Wextra -g -O C++ Compiler user flags: -Wno-overloaded-virtual Linker flags: Linker user flags: Qt Frontend: Qt version: 4.8.6 Packaging: posix LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx-master [...] ../../master/src/CutAndPaste.cpp:390:15: error: call to 'next' is ambiguous pars.insert(next(pars.begin(), pit), ^~~~ /usr/include/c++/v1/iterator:512:1: note: candidate function [with _ForwardIter = std::__1::__list_iterator] next(_ForwardIter __x, ^ ../../master/src/support/lyxalgo.h:92:11: note: candidate function [with It = std::__1::__list_iterator, Diff = long] inline It next(It i, Diff n = 1) ^
Re: Build questions for OS X
Le 08/07/2015 20:46, Georg Baum a écrit : Jean-Marc Lasgouttes wrote: I have seen that too. I did not think about enforcing c++98. Shall I try that? I think that would be a good idea at least for newer compilers (e.g. for gcc version 5 and newer, for clang probably always). From what I understand, the problem is only with libc++ (the clang Standard library) and on this one setting std=c++98 does not change anything. I just tried that with clang 3.6 and compilation fails. We should maybe make c++11 the default for new enough compilers. JMarc
Re: Build questions for OS X
Am 09.07.2015 um 03:21 schrieb Jerry : > > On Jul 8, 2015, at 4:48 PM, Jerry wrote: > >> >> On Jul 8, 2015, at 9:09 AM, Stephan Witt wrote: >> >>> Am 08.07.2015 um 13:08 schrieb Jerry : >>> On Jul 8, 2015, at 3:32 AM, Stephan Witt wrote: > Am 08.07.2015 um 12:06 schrieb Jerry : > >> >> On Jul 7, 2015, at 10:54 PM, Stephan Witt wrote: >> >>> Am 08.07.2015 um 01:20 schrieb Jerry : >>> >>> 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: >> >> CXXLDlyx >> Undefined symbols for architecture x86_64: >> "decltype(*(std::__1::forward(fp0)).*fp(std::__1::forward<>(fp1))) >> std::__1::__invoke> lyx::frontend::GuiWorkArea*&, void>(void >> (lyx::frontend::GuiWorkArea::*&&&)(), lyx::frontend::GuiWorkArea*&&&)", >> referenced from: >> >> boost::detail::function::void_function_obj_invoker0> (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 targ
Re: Build questions for OS X
On Jul 8, 2015, at 4:48 PM, Jerry wrote: > > On Jul 8, 2015, at 9:09 AM, Stephan Witt wrote: > >> Am 08.07.2015 um 13:08 schrieb Jerry : >> >>> >>> On Jul 8, 2015, at 3:32 AM, Stephan Witt wrote: >>> Am 08.07.2015 um 12:06 schrieb Jerry : > > On Jul 7, 2015, at 10:54 PM, Stephan Witt wrote: > >> Am 08.07.2015 um 01:20 schrieb Jerry : >> >> 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: > > CXXLDlyx > Undefined symbols for architecture x86_64: > > "decltype(*(std::__1::forward(fp0)).*fp(std::__1::forward<>(fp1))) > std::__1::__invoke lyx::frontend::GuiWorkArea*&, void>(void > (lyx::frontend::GuiWorkArea::*&&&)(), lyx::frontend::GuiWorkArea*&&&)", > referenced from: > > boost::detail::function::void_function_obj_invoker0 (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-d
Re: Build questions for OS X
On Jul 8, 2015, at 9:09 AM, Stephan Witt wrote: > Am 08.07.2015 um 13:08 schrieb Jerry : > >> >> On Jul 8, 2015, at 3:32 AM, Stephan Witt wrote: >> >>> Am 08.07.2015 um 12:06 schrieb Jerry : >>> On Jul 7, 2015, at 10:54 PM, Stephan Witt wrote: > Am 08.07.2015 um 01:20 schrieb Jerry : > > 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: CXXLDlyx Undefined symbols for architecture x86_64: "decltype(*(std::__1::forward(fp0)).*fp(std::__1::forward<>(fp1))) std::__1::__invoke(void (lyx::frontend::GuiWorkArea::*&&&)(), lyx::frontend::GuiWorkArea*&&&)", referenced from: boost::detail::function::void_function_obj_invoker0, 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
Re: Build questions for OS X
Jean-Marc Lasgouttes wrote: > I have seen that too. I did not think about enforcing c++98. Shall I try > that? I think that would be a good idea at least for newer compilers (e.g. for gcc version 5 and newer, for clang probably always). > The alternative would be to enforce c++11 for 2.2, but I am not sure > that all of our supported platforma sare ready for that. I have the > feeling that we discussed that already, but I cannot find it. IIRC we decided that it is too early for 2.2 and to require C++11 for the next major version after 2.2. Otherwise we could already get rid of some boost parts. Georg
Re: Build questions for OS X
Jean-Marc Lasgouttes wrote: > I have seen that too. I did not think about enforcing c++98. Shall I try > that? I think that would be a good idea at least for newer compilers (e.g. for gcc version 5 and newer, for clang probably always). > The alternative would be to enforce c++11 for 2.2, but I am not sure > that all of our supported platforma sare ready for that. I have the > feeling that we discussed that already, but I cannot find it. IIRC we decided that it is too early for 2.2 and to require C++11 for the next major version after 2.2. Otherwise we could already get rid of some boost parts. Georg
Re: Build questions for OS X
Am 08.07.2015 um 13:08 schrieb Jerry : > > On Jul 8, 2015, at 3:32 AM, Stephan Witt wrote: > >> Am 08.07.2015 um 12:06 schrieb Jerry : >> >>> >>> On Jul 7, 2015, at 10:54 PM, Stephan Witt wrote: >>> Am 08.07.2015 um 01:20 schrieb Jerry : 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
Re: Build questions for OS X
On Jul 8, 2015, at 3:32 AM, Stephan Witt wrote: > Am 08.07.2015 um 12:06 schrieb Jerry : > >> >> On Jul 7, 2015, at 10:54 PM, Stephan Witt wrote: >> >>> Am 08.07.2015 um 01:20 schrieb Jerry : >>> On Jul 7, 2015, at 12:38 PM, Georg Baum 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] >>> next(_ForwardIter __x, >>> ^ >>> ./support/lyxalgo.h:92:11: note: candidate function [with It = >>> std::__1::__list_iterator, 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 CXXLDlyx Undefined symbols for architecture x86_64: "decltype(*(std::__1::forward(fp0)).*fp(std::__1::forward<>(fp1))) std::__1::__invoke>>> lyx::frontend::GuiWorkArea*&, void>(void (lyx::frontend::GuiWorkArea::*&&&)(), lyx::frontend::GuiWorkArea*&&&)", referenced from: boost::detail::function::void_function_obj_invoker0>>> (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-versio
Re: Build questions for OS X
Am 08.07.2015 um 12:06 schrieb Jerry : > > On Jul 7, 2015, at 10:54 PM, Stephan Witt wrote: > >> Am 08.07.2015 um 01:20 schrieb Jerry : >> >>> >>> On Jul 7, 2015, at 12:38 PM, Georg Baum >>> 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] >> next(_ForwardIter __x, >> ^ >> ./support/lyxalgo.h:92:11: note: candidate function [with It = >>std::__1::__list_iterator, 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 >>> >>> >>> CXXLDlyx >>> Undefined symbols for architecture x86_64: >>> "decltype(*(std::__1::forward(fp0)).*fp(std::__1::forward<>(fp1))) >>> std::__1::__invoke>> lyx::frontend::GuiWorkArea*&, void>(void >>> (lyx::frontend::GuiWorkArea::*&&&)(), lyx::frontend::GuiWorkArea*&&&)", >>> referenced from: >>> >>> boost::detail::function::void_function_obj_invoker0>> (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 doe
Re: Build questions for OS X
On Jul 7, 2015, at 10:54 PM, Stephan Witt wrote: > Am 08.07.2015 um 01:20 schrieb Jerry : > >> >> On Jul 7, 2015, at 12:38 PM, Georg Baum >> 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] > next(_ForwardIter __x, > ^ > ./support/lyxalgo.h:92:11: note: candidate function [with It = > std::__1::__list_iterator, 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 >> >> >> CXXLDlyx >> Undefined symbols for architecture x86_64: >> "decltype(*(std::__1::forward(fp0)).*fp(std::__1::forward<>(fp1))) >> std::__1::__invoke> lyx::frontend::GuiWorkArea*&, void>(void >> (lyx::frontend::GuiWorkArea::*&&&)(), lyx::frontend::GuiWorkArea*&&&)", >> referenced from: >> >> boost::detail::function::void_function_obj_invoker0> (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 al
Re: Build questions for OS X
Le 07/07/2015 21:38, Georg Baum a écrit : 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. I have seen that too. I did not think about enforcing c++98. Shall I try that? The alternative would be to enforce c++11 for 2.2, but I am not sure that all of our supported platforma sare ready for that. I have the feeling that we discussed that already, but I cannot find it. JMarc
Re: Build questions for OS X
Am 08.07.2015 um 01:20 schrieb Jerry : > > On Jul 7, 2015, at 12:38 PM, Georg Baum > 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] next(_ForwardIter __x, ^ ./support/lyxalgo.h:92:11: note: candidate function [with It = std::__1::__list_iterator, 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 > > > CXXLDlyx > Undefined symbols for architecture x86_64: > > "decltype(*(std::__1::forward(fp0)).*fp(std::__1::forward<>(fp1))) > std::__1::__invoke lyx::frontend::GuiWorkArea*&, void>(void > (lyx::frontend::GuiWorkArea::*&&&)(), lyx::frontend::GuiWorkArea*&&&)", > referenced from: > > boost::detail::function::void_function_obj_invoker0 (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
Re: Build questions for OS X
On Jul 7, 2015, at 4:20 PM, Jerry wrote: > The linker might have found my Qt4 installation from MacPorts. I don't know > if it is 32-bit or 64-bit or both. It is 64-bit only. Jerry
Re: Build questions for OS X
On Jul 7, 2015, at 12:38 PM, Georg Baum 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] >>> next(_ForwardIter __x, >>> ^ >>> ./support/lyxalgo.h:92:11: note: candidate function [with It = >>> std::__1::__list_iterator, 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 CXXLDlyx Undefined symbols for architecture x86_64: "decltype(*(std::__1::forward(fp0)).*fp(std::__1::forward<>(fp1))) std::__1::__invoke(void (lyx::frontend::GuiWorkArea::*&&&)(), lyx::frontend::GuiWorkArea*&&&)", referenced from: boost::detail::function::void_function_obj_invoker0, 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 Jerry config.log Description: Binary data
Re: Build questions for OS X
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] >> next(_ForwardIter __x, >> ^ >> ./support/lyxalgo.h:92:11: note: candidate function [with It = >>std::__1::__list_iterator, 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.
Re: Build questions for OS X
On Jul 6, 2015, at 11:26 PM, Stephan Witt wrote: > Can you send us your config.log privately, please? > > Stephan Done. Sent to Stephan, JMarc, and Georg. Jerry
Re: Build questions for OS X
Le 07/07/2015 01:07, Jerry a écrit : #!/bin/bash cd /Applications/Words/LyXOuterFolder/git/lyx/ ./autogen.sh ./configure \ --with-version-suffix=-2.3 \ --with-libiconv-prefix=/usr/lib \ --with-x=no \ --disable-stdlib-debug \ --prefix=/Applications/Words/LyXOuterFolder/git \ --with-qt-dir="/Applications/Words/LyXOuterFolder/git/qt/Qt Creator.app/Contents/Frameworks/" make make install-strip 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] next(_ForwardIter __x, ^ ./support/lyxalgo.h:92:11: note: candidate function [with It = std::__1::__list_iterator, Diff = long] inline It next(It i, Diff n = 1) What happens if you add --enable-cxx1 to the configure command-line? JMarc
Re: Build questions for OS X
Am 07.07.2015 um 05:40 schrieb Jerry : > On Jul 6, 2015, at 4:45 PM, Stephan Witt wrote: >>> >>> The process failed with these apparent C++ errors: >> >> I think I've seen these errors with Xcode 6 and the accompanying clang >> compiler. >> It has something to do with cxx11 if I'm not mistaken. Sorry, I forgot the >> details. >> I'm on Xcode 5 and Mac OS X 10.8.6 for my daily work. > > I'm on OS X 10.9.5 and Xcode 5.1.1 so maybe it's not an Xcode issue. Ok, this is the same version I'm using. > These problems appear to be either C coding errors or a clang error. In > either case it will stop my build efforts because I don't know how to write C > etc. FWIW I still have an older Xcode, 3.2.6, at > /Developer/Applications/Xcode.app. I'm not sure if this works. > Should I report a bug for this? We're on the developers list anyway. Perhaps JMarc or Georg has an idea!? Can you send us your config.log privately, please? Stephan > > Jerry > >> >>> /Applications/Xcode.app/Contents/Developer/usr/bin/make install-am >>> make[7]: Nothing to be done for `install-exec-am'. >>> make[7]: Nothing to be done for `install-data-am'. >>> Making install in . >>> make[6]: Nothing to be done for `install-exec-am'. >>> make[6]: Nothing to be done for `install-data-am'. >>> Making install in . >>> 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] >>> next(_ForwardIter __x, >>> ^ >>> ./support/lyxalgo.h:92:11: note: candidate function [with It = >>>std::__1::__list_iterator, Diff = long] >>> inline It next(It i, Diff n = 1) >>>^ >>> CutAndPaste.cpp:398:15: error: call to 'next' is ambiguous >>> pars.insert(next(pars.begin(), pit + 1), >>> ^~~~ >>> /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] >>> next(_ForwardIter __x, >>> ^ >>> ./support/lyxalgo.h:92:11: note: candidate function [with It = >>>std::__1::__list_iterator, Diff = long] >>> inline It next(It i, Diff n = 1) >>>^ >>> CutAndPaste.cpp:602:26: error: call to 'next' is ambiguous >>> ParagraphList copy_pars(next(pars.begin(), startpit), >>> ^~~~ >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iterator:509:1: >>> note: >>>candidate function [with _ForwardIter = >>> std::__1::__list_const_iterator>>*>] >>> next(_ForwardIter __x, >>> ^ >>> ./support/lyxalgo.h:92:11: note: candidate function [with It = >>>std::__1::__list_const_iterator, Diff = long] >>> inline It next(It i, Diff n = 1) >>>^ >>> 3 errors generated. >>> make[4]: *** [CutAndPaste.o] Error 1 >>> make[3]: *** [install-recursive] Error 1 >>> make[2]: *** [install] Error 2 >>> make[1]: *** [install-recursive] Error 1 >>> make: *** [install-strip] Error 2 >>> >>> >>> >>> >>> These notwithstanding, it looks like there could be Qt problems later. I >>> spotted the following lines: >>> >>> checking whether Qt5 is requested... no >>> >>> and >>> >>> Configuration >>> ... >>> Qt Frontend: >>>Qt version: 4.8.7 >>> ... >>> >>> Qt 4.8.7 is my MacPorts installation. >>> >>> FWIW, I see that in config.log, this appears: >>> >>> --with-qt-dir=/Applications/Words/LyXOuterFolder/git/qt/Qt >>> Creator.app/Contents/Frameworks/ >>>^ note space >>> >>> Notice that the quotes from my script have been removed. >> >> Yes, that's the difference between the ideal and the real world. >> Unix is able to handle spaces in path names as long as nobody makes a >> mistake. >> One has to quote every path name variable in scripts - it is not automatic. >> Since the configure script is generated by auto tools I think it would be >> easier to solve it pragmatically instead of getting it right. >> >> The practical solution is to rename your Qt Creator application name and >> remove the space from path name. I think it doesn't break the app - >> at least it should not. >> >> Regards, Stephan >
Re: Build questions for OS X
On Jul 6, 2015, at 4:45 PM, Stephan Witt wrote: >> >> The process failed with these apparent C++ errors: > > I think I've seen these errors with Xcode 6 and the accompanying clang > compiler. > It has something to do with cxx11 if I'm not mistaken. Sorry, I forgot the > details. > I'm on Xcode 5 and Mac OS X 10.8.6 for my daily work. I'm on OS X 10.9.5 and Xcode 5.1.1 so maybe it's not an Xcode issue. These problems appear to be either C coding errors or a clang error. In either case it will stop my build efforts because I don't know how to write C etc. FWIW I still have an older Xcode, 3.2.6, at /Developer/Applications/Xcode.app. Should I report a bug for this? Jerry > >> /Applications/Xcode.app/Contents/Developer/usr/bin/make install-am >> make[7]: Nothing to be done for `install-exec-am'. >> make[7]: Nothing to be done for `install-data-am'. >> Making install in . >> make[6]: Nothing to be done for `install-exec-am'. >> make[6]: Nothing to be done for `install-data-am'. >> Making install in . >> 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] >> next(_ForwardIter __x, >> ^ >> ./support/lyxalgo.h:92:11: note: candidate function [with It = >> std::__1::__list_iterator, Diff = long] >> inline It next(It i, Diff n = 1) >> ^ >> CutAndPaste.cpp:398:15: error: call to 'next' is ambiguous >> pars.insert(next(pars.begin(), pit + 1), >> ^~~~ >> /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] >> next(_ForwardIter __x, >> ^ >> ./support/lyxalgo.h:92:11: note: candidate function [with It = >> std::__1::__list_iterator, Diff = long] >> inline It next(It i, Diff n = 1) >> ^ >> CutAndPaste.cpp:602:26: error: call to 'next' is ambiguous >> ParagraphList copy_pars(next(pars.begin(), startpit), >> ^~~~ >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iterator:509:1: >> note: >> candidate function [with _ForwardIter = >> std::__1::__list_const_iterator> *>] >> next(_ForwardIter __x, >> ^ >> ./support/lyxalgo.h:92:11: note: candidate function [with It = >> std::__1::__list_const_iterator, Diff = long] >> inline It next(It i, Diff n = 1) >> ^ >> 3 errors generated. >> make[4]: *** [CutAndPaste.o] Error 1 >> make[3]: *** [install-recursive] Error 1 >> make[2]: *** [install] Error 2 >> make[1]: *** [install-recursive] Error 1 >> make: *** [install-strip] Error 2 >> >> >> >> >> These notwithstanding, it looks like there could be Qt problems later. I >> spotted the following lines: >> >> checking whether Qt5 is requested... no >> >> and >> >> Configuration >> ... >> Qt Frontend: >> Qt version: 4.8.7 >> ... >> >> Qt 4.8.7 is my MacPorts installation. >> >> FWIW, I see that in config.log, this appears: >> >> --with-qt-dir=/Applications/Words/LyXOuterFolder/git/qt/Qt >> Creator.app/Contents/Frameworks/ >> ^ note space >> >> Notice that the quotes from my script have been removed. > > Yes, that's the difference between the ideal and the real world. > Unix is able to handle spaces in path names as long as nobody makes a mistake. > One has to quote every path name variable in scripts - it is not automatic. > Since the configure script is generated by auto tools I think it would be > easier to solve it pragmatically instead of getting it right. > > The practical solution is to rename your Qt Creator application name and > remove the space from path name. I think it doesn't break the app - > at least it should not. > > Regards, Stephan
Re: Build questions for OS X
Am 07.07.2015 um 01:07 schrieb Jerry : > On Jul 5, 2015, at 10:58 PM, Stephan Witt wrote: > >>> If anything I have said above makes it look like I have a clue what I am >>> doing it is wrong--I'm at least 50% clueless here. >> >> Which version/installation of Qt you'll use is determined by the >> --with-qt-dir switch for autotools builds. >> In case you're using cmake as build system you have to set your PATH >> variable appropriately. >> The directory where qmake is installed should come first, e.g. my cmake >> build scripts contains >> export PATH="/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/bin:${PATH}" >> >> Regards, Stephan > > Thanks for those remarks, Stephan. > > Here is what I have done. I downloaded part of Qt from > https://www.qt.io/download/; from the installer program provided therefrom, I > selected only the gcc pre-built option. What I got was Qt Creator.app with > frameworks installed inside the app bundle. This is version 5.5, new as of > only a few days ago. The paths to the LyX repo and Qt frameworks are this: > > /Applications/Words/LyXOuterFolder/git/lyx/ > /Applications/Words/LyXOuterFolder/git/qt/Qt Creator.app/Contents/Frameworks/ > > I ran the following script which is slightly modified from the script in > INSTALL.MacOSX: > > > #!/bin/bash > cd /Applications/Words/LyXOuterFolder/git/lyx/ > ./autogen.sh > ./configure \ > --with-version-suffix=-2.3 \ > --with-libiconv-prefix=/usr/lib \ > --with-x=no \ > --disable-stdlib-debug \ > --prefix=/Applications/Words/LyXOuterFolder/git \ > --with-qt-dir="/Applications/Words/LyXOuterFolder/git/qt/Qt > Creator.app/Contents/Frameworks/" > make > make install-strip I recommend out-of-source-tree builds. You avoid the pollution of your git clone with generated objects this way. Starting over is as simple as removing the complete build folder. Make a sibling folder to build LyX there, e.g. $ cd /Applications/Words/LyXOuterFolder/git $ mkdir -p build $ (cd lyx ; ./autogen.sh) $ (cd build ; ../lyx/configure --with-version-suffix=-2.3 … && make && make install-strip) > I used the superstition of setting the version to 2.3 hoping that it might > not clobber version 2.2 stuff in the Applications Support folder. Yes, this will work. But I think you can choose any more private string, like --with-version-suffix=-2.X or similar. > > The process failed with these apparent C++ errors: I think I've seen these errors with Xcode 6 and the accompanying clang compiler. It has something to do with cxx11 if I'm not mistaken. Sorry, I forgot the details. I'm on Xcode 5 and Mac OS X 10.8.6 for my daily work. > /Applications/Xcode.app/Contents/Developer/usr/bin/make install-am > make[7]: Nothing to be done for `install-exec-am'. > make[7]: Nothing to be done for `install-data-am'. > Making install in . > make[6]: Nothing to be done for `install-exec-am'. > make[6]: Nothing to be done for `install-data-am'. > Making install in . > 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] > next(_ForwardIter __x, > ^ > ./support/lyxalgo.h:92:11: note: candidate function [with It = > std::__1::__list_iterator, Diff = long] > inline It next(It i, Diff n = 1) > ^ > CutAndPaste.cpp:398:15: error: call to 'next' is ambiguous >pars.insert(next(pars.begin(), pit + 1), >^~~~ > /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] > next(_ForwardIter __x, > ^ > ./support/lyxalgo.h:92:11: note: candidate function [with It = > std::__1::__list_iterator, Diff = long] > inline It next(It i, Diff n = 1) > ^ > CutAndPaste.cpp:602:26: error: call to 'next' is ambiguous >ParagraphList copy_pars(next(pars.begin(), startpit), >^~~~ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iterator:509:1: > note: > candidate function [with _ForwardIter = > std::__1::__list_const_iterator *>] > next(_ForwardIter __x, > ^ > ./support/lyxalgo.h:92:11: note: candidate function [with It = > std::__1::__list_const_iterator, Diff = long] > inline It next(It i, Diff n = 1) > ^ > 3 errors generated. > make[4]: *** [CutAndPaste.o] Error 1 > make[3]: *** [install-recursive] Error 1 > make[2]: *** [install] Error 2 > make[1]: *** [install-recursive] Error 1 > make: *** [install-strip] Error 2 > > > > > These notwithstanding, it looks like there could be Qt problems later. I >
Re: Build questions for OS X
On Jul 5, 2015, at 10:58 PM, Stephan Witt wrote: >> If anything I have said above makes it look like I have a clue what I am >> doing it is wrong--I'm at least 50% clueless here. > > Which version/installation of Qt you'll use is determined by the > --with-qt-dir switch for autotools builds. > In case you're using cmake as build system you have to set your PATH variable > appropriately. > The directory where qmake is installed should come first, e.g. my cmake build > scripts contains > export PATH="/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/bin:${PATH}" > > Regards, Stephan Thanks for those remarks, Stephan. Here is what I have done. I downloaded part of Qt from https://www.qt.io/download/; from the installer program provided therefrom, I selected only the gcc pre-built option. What I got was Qt Creator.app with frameworks installed inside the app bundle. This is version 5.5, new as of only a few days ago. The paths to the LyX repo and Qt frameworks are this: /Applications/Words/LyXOuterFolder/git/lyx/ /Applications/Words/LyXOuterFolder/git/qt/Qt Creator.app/Contents/Frameworks/ I ran the following script which is slightly modified from the script in INSTALL.MacOSX: #!/bin/bash cd /Applications/Words/LyXOuterFolder/git/lyx/ ./autogen.sh ./configure \ --with-version-suffix=-2.3 \ --with-libiconv-prefix=/usr/lib \ --with-x=no \ --disable-stdlib-debug \ --prefix=/Applications/Words/LyXOuterFolder/git \ --with-qt-dir="/Applications/Words/LyXOuterFolder/git/qt/Qt Creator.app/Contents/Frameworks/" make make install-strip I used the superstition of setting the version to 2.3 hoping that it might not clobber version 2.2 stuff in the Applications Support folder. The process failed with these apparent C++ errors: /Applications/Xcode.app/Contents/Developer/usr/bin/make install-am make[7]: Nothing to be done for `install-exec-am'. make[7]: Nothing to be done for `install-data-am'. Making install in . make[6]: Nothing to be done for `install-exec-am'. make[6]: Nothing to be done for `install-data-am'. Making install in . 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] next(_ForwardIter __x, ^ ./support/lyxalgo.h:92:11: note: candidate function [with It = std::__1::__list_iterator, Diff = long] inline It next(It i, Diff n = 1) ^ CutAndPaste.cpp:398:15: error: call to 'next' is ambiguous pars.insert(next(pars.begin(), pit + 1), ^~~~ /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] next(_ForwardIter __x, ^ ./support/lyxalgo.h:92:11: note: candidate function [with It = std::__1::__list_iterator, Diff = long] inline It next(It i, Diff n = 1) ^ CutAndPaste.cpp:602:26: error: call to 'next' is ambiguous ParagraphList copy_pars(next(pars.begin(), startpit), ^~~~ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/iterator:509:1: note: candidate function [with _ForwardIter = std::__1::__list_const_iterator] next(_ForwardIter __x, ^ ./support/lyxalgo.h:92:11: note: candidate function [with It = std::__1::__list_const_iterator, Diff = long] inline It next(It i, Diff n = 1) ^ 3 errors generated. make[4]: *** [CutAndPaste.o] Error 1 make[3]: *** [install-recursive] Error 1 make[2]: *** [install] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install-strip] Error 2 These notwithstanding, it looks like there could be Qt problems later. I spotted the following lines: checking whether Qt5 is requested... no and Configuration ... Qt Frontend: Qt version: 4.8.7 ... Qt 4.8.7 is my MacPorts installation. FWIW, I see that in config.log, this appears: --with-qt-dir=/Applications/Words/LyXOuterFolder/git/qt/Qt Creator.app/Contents/Frameworks/ ^ note space Notice that the quotes from my script have been removed. Jerry
Re: Build questions for OS X
Am 06.07.2015 um 00:42 schrieb Jerry : > I am attempting to build LyX on OS X for testing purposes, not distribution. > > I have all of the prerequisites installed via MacPorts except possibly Qt, as > described below. The installation of Qt on the build machine is possible in three different ways. 1. The installer from Qt 2. The MacPorts package (or similar 3rd-party package tool) 3. Build from source I think you may choose any of them to get a working LyX. I'm using the 3rd way only. That way I can build a package with autotools and a private Qt framework bundled with LyX. Such a bundle is the only way to provide a LyX for Mac users without forcing them to download and install the Qt-packages themselves or installing MacPorts. Regarding the Qt4 vs Qt5 question: I recommend to use the Qt5 packages. Although it's possible to get the sources for 4.8.x it's not the future. Unfortunately all the Mac version of Qt5 has some nasty bugs. Some developers using Qt for their software packages decided to stick with 4.8.x therefore. (I've read this in Qt-blogs and comments on Qt5-releases. ATM I have no links.) In case you're interested in Retina-support you have to use Qt5 anyway. > > I have done the git checkout and am looking at INSTALL.MacOSX. Another source of information is the script "development/LyX-Mac-binary-release.sh" > > The download link(s) in INSTALL.MacOSX for Qt are out of date, listing a > trolltech web site and a Nokia FTP site. I found and downloaded a OS X > installer from https://www.qt.io/download-open-source/ which promises to > download binaries and source. Will this work? Can I download only binaries? I > have not proceeded with this step because… I did not try that. But on a Mac it should be possible. A Mac framework comes with all header files to compile and link your own software against it. To be able to step into the Qt-code you'll need the debug-version of the frameworks. The source package is only needed for the 3rd option mentioned above. > > ...INSTALL.MacOSX says to install Qt 4 but the qt.io site provides an > installer only for Qt 5 with a pre-built option for only 64-bit. Will Qt 5 > work? If not, where can I get Qt 4?… Yes, Qt5 will work. There is no 32bit support for Qt anymore. It simply fails to compile if you try it. For Qt4 you have to compile the frameworks yourself - option 3 above. > > ...I already have Qt installed on my machine via MacPorts which reports that > I have qt4-mac 4.8.7_0 as the active installation. qt5-mac 5.4.2 is available > but not installed. Will a MacPorts version of Qt work? How? Again, I didn't try that. For local development it should work. I failed to build a distribution package with it in the past because of the massive MacPorts dependencies LyX acquires that way. > If anything I have said above makes it look like I have a clue what I am > doing it is wrong--I'm at least 50% clueless here. Which version/installation of Qt you'll use is determined by the --with-qt-dir switch for autotools builds. In case you're using cmake as build system you have to set your PATH variable appropriately. The directory where qmake is installed should come first, e.g. my cmake build scripts contains export PATH="/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/bin:${PATH}" Regards, Stephan
Build questions for OS X
I am attempting to build LyX on OS X for testing purposes, not distribution. I have all of the prerequisites installed via MacPorts except possibly Qt, as described below. I have done the git checkout and am looking at INSTALL.MacOSX. The download link(s) in INSTALL.MacOSX for Qt are out of date, listing a trolltech web site and a Nokia FTP site. I found and downloaded a OS X installer from https://www.qt.io/download-open-source/ which promises to download binaries and source. Will this work? Can I download only binaries? I have not proceeded with this step because... ...INSTALL.MacOSX says to install Qt 4 but the qt.io site provides an installer only for Qt 5 with a pre-built option for only 64-bit. Will Qt 5 work? If not, where can I get Qt 4?... ...I already have Qt installed on my machine via MacPorts which reports that I have qt4-mac 4.8.7_0 as the active installation. qt5-mac 5.4.2 is available but not installed. Will a MacPorts version of Qt work? How? If anything I have said above makes it look like I have a clue what I am doing it is wrong--I'm at least 50% clueless here. Jerry