subject:"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_iteratorlyx::Paragraph, void *]
next(_ForwardIter __x,
^
../../master/src/support/lyxalgo.h:92:11: note: candidate function [with 
It =

  std::__1::__list_iteratorlyx::Paragraph, void *, 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

2015-07-09 Thread 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.


Georg

Re: Build questions for OS X

2015-07-09 Thread Stephan Witt

Am 09.07.2015 um 21:39 schrieb Georg Baum georg.b...@post.rwth-aachen.de:

 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


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


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

2015-07-09 Thread 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.


Georg

Re: Build questions for OS X

2015-07-09 Thread Stephan Witt

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


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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
   std::__1::__list_iteratorlyx::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
 
 
 CXXLDlyx
 Undefined symbols for architecture x86_64:
 decltype(*(std::__1::forwardlyx::frontend::GuiWorkArea*(fp0)).*fp(std::__1::forward(fp1)))
  std::__1::__invokevoid (lyx::frontend::GuiWorkArea::*)(), 
 lyx::frontend::GuiWorkArea*, void(void 
 (lyx::frontend::GuiWorkArea::*)(), lyx::frontend::GuiWorkArea*), 
 referenced from:
   
 boost::detail::function::void_function_obj_invoker0std::__1::__bindvoid 
 (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

Re: Build questions for OS X

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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
std::__1::__list_iteratorlyx::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
 
 
 CXXLDlyx
 Undefined symbols for architecture x86_64:
 decltype(*(std::__1::forwardlyx::frontend::GuiWorkArea*(fp0)).*fp(std::__1::forward(fp1)))
  std::__1::__invokevoid (lyx::frontend::GuiWorkArea::*)(), 
 lyx::frontend::GuiWorkArea*, void(void 
 (lyx::frontend::GuiWorkArea::*)(), lyx::frontend::GuiWorkArea*), 
 referenced from:

 boost::detail::function::void_function_obj_invoker0std::__1::__bindvoid 
 (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

Re: Build questions for OS X


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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
 std::__1::__list_iteratorlyx::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
 
 
 CXXLDlyx
 Undefined symbols for architecture x86_64:
 decltype(*(std::__1::forwardlyx::frontend::GuiWorkArea*(fp0)).*fp(std::__1::forward(fp1)))
  std::__1::__invokevoid (lyx::frontend::GuiWorkArea::*)(), 
 lyx::frontend::GuiWorkArea*, void(void 
 (lyx::frontend::GuiWorkArea::*)(), lyx::frontend::GuiWorkArea*), 
 referenced from:
 
 boost::detail::function::void_function_obj_invoker0std::__1::__bindvoid 
 (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

Re: Build questions for OS X

2015-07-08 Thread Jean-Marc Lasgouttes


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 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

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 09.07.2015 um 03:21 schrieb Jerry lancebo...@qwest.net:

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:

CXXLDlyx
Undefined symbols for architecture x86_64:
decltype(*(std::__1::forwardlyx::frontend::GuiWorkArea*(fp0)).*fp(std::__1::forward(fp1)))
std::__1::__invokevoid (lyx::frontend::GuiWorkArea::*)(),
lyx::frontend::GuiWorkArea*, void(void
(lyx::frontend::GuiWorkArea::*)(), lyx::frontend::GuiWorkArea*),
referenced from:

boost::detail::function::void_function_obj_invoker0std::__1::__bindvoid
(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

With it it's not working if the framework name is not e.g. QtCore5.

and (2) removed the path to the Qt5 frameworks,

Re: Build questions for OS X

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.

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.

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.

This one I cannot answer. I'd try it probably.

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'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:

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

Re: Build questions for OS X

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.

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.

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'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::forwardlyx::frontend::GuiWorkArea*(fp0)).*fp(std::__1::forward(fp1)))
std::__1::__invokevoid (lyx::frontend::GuiWorkArea::*)(),
lyx::frontend::GuiWorkArea*, void(void (lyx::frontend::GuiWorkArea::*)(),
lyx::frontend::GuiWorkArea*), referenced from:
boost::detail::function::void_function_obj_invoker0std::__1::__bindvoid
(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

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

2015-07-08 Thread Jean-Marc Lasgouttes


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


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

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

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

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

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


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::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


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, 
> 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

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

Re: Build questions for OS X

Am 07.07.2015 um 05:40 schrieb Jerry lancebo...@qwest.net:

 On Jul 6, 2015, at 4:45 PM, Stephan Witt st.w...@gmx.net 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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
std::__1::__list_iteratorlyx::Paragraph, void *, 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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
std::__1::__list_iteratorlyx::Paragraph, void *, 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_iteratorlyx::Paragraph, void
*]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
std::__1::__list_const_iteratorlyx::Paragraph, void *, 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

2015-07-07 Thread Jean-Marc Lasgouttes


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_iteratorlyx::Paragraph, void *]
next(_ForwardIter __x,
^
./support/lyxalgo.h:92:11: note: candidate function [with It =
   std::__1::__list_iteratorlyx::Paragraph, void *, 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

2015-07-07 Thread Georg Baum

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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
std::__1::__list_iteratorlyx::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.

Re: Build questions for OS X


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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
   std::__1::__list_iteratorlyx::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


  CXXLDlyx
Undefined symbols for architecture x86_64:
  
decltype(*(std::__1::forwardlyx::frontend::GuiWorkArea*(fp0)).*fp(std::__1::forward(fp1)))
 std::__1::__invokevoid (lyx::frontend::GuiWorkArea::*)(), 
lyx::frontend::GuiWorkArea*, void(void (lyx::frontend::GuiWorkArea::*)(), 
lyx::frontend::GuiWorkArea*), referenced from:
  boost::detail::function::void_function_obj_invoker0std::__1::__bindvoid 
(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

Jerry



config.log
Description: Binary data

Re: Build questions for OS X


On Jul 6, 2015, at 11:26 PM, Stephan Witt st.w...@gmx.net 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


On Jul 7, 2015, at 4:20 PM, Jerry lancebo...@qwest.net 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

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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
  std::__1::__list_iteratorlyx::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
 
 
  CXXLDlyx
 Undefined symbols for architecture x86_64:
  
 decltype(*(std::__1::forwardlyx::frontend::GuiWorkArea*(fp0)).*fp(std::__1::forward(fp1)))
  std::__1::__invokevoid (lyx::frontend::GuiWorkArea::*)(), 
 lyx::frontend::GuiWorkArea*, void(void 
 (lyx::frontend::GuiWorkArea::*)(), lyx::frontend::GuiWorkArea*), 
 referenced from:
  
 boost::detail::function::void_function_obj_invoker0std::__1::__bindvoid 
 (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

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

2015-07-07 Thread Jean-Marc Lasgouttes


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


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

2015-07-07 Thread Georg Baum

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 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::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


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

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, 
> 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

Re: Build questions for OS X

On Jul 5, 2015, at 10:58 PM, Stephan Witt st.w...@gmx.net wrote:
snip
 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_iteratorlyx::Paragraph, void *]
next(_ForwardIter __x,
^
./support/lyxalgo.h:92:11: note: candidate function [with It =
  std::__1::__list_iteratorlyx::Paragraph, void *, 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_iteratorlyx::Paragraph, void *]
next(_ForwardIter __x,
^
./support/lyxalgo.h:92:11: note: candidate function [with It =
  std::__1::__list_iteratorlyx::Paragraph, void *, 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_iteratorlyx::Paragraph, void
  *]
next(_ForwardIter __x,
^
./support/lyxalgo.h:92:11: note: candidate function [with It =
  std::__1::__list_const_iteratorlyx::Paragraph, void *, 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

2015-07-06 Thread Stephan Witt

Am 07.07.2015 um 01:07 schrieb Jerry lancebo...@qwest.net:

 On Jul 5, 2015, at 10:58 PM, Stephan Witt st.w...@gmx.net wrote:
 snip
 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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
  std::__1::__list_iteratorlyx::Paragraph, void *, 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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
  std::__1::__list_iteratorlyx::Paragraph, void *, 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_iteratorlyx::Paragraph, void
  *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
  std::__1::__list_const_iteratorlyx::Paragraph, void *, 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

Re: Build questions for OS X

On Jul 6, 2015, at 4:45 PM, Stephan Witt st.w...@gmx.net 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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
 std::__1::__list_iteratorlyx::Paragraph, void *, 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_iteratorlyx::Paragraph, void *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
 std::__1::__list_iteratorlyx::Paragraph, void *, 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_iteratorlyx::Paragraph, void
 *]
 next(_ForwardIter __x,
 ^
 ./support/lyxalgo.h:92:11: note: candidate function [with It =
 std::__1::__list_const_iteratorlyx::Paragraph, void *, 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 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

2015-07-06 Thread Stephan Witt

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]: ***

Re: Build questions for OS X