Re: Status on Mac with El Capitan
Jean-Marc Lasgouttes wrote: > Le 08/01/2016 10:08, Stephan Witt a écrit : >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : >>> Yes, unless somone has a different brilliant idea. > >>> This problem will go away in 2.3. >> >> How? With your fix? Does it fix wrong LyX code or is it some work around? > > Because support for c++98 will go away, together with many of our lyx:: > wrappers. > > Georg, do you have a thought on that? Sorry, I did not read this message earlier. Although it is not nice I think this is the best we can do for now, so I am fine with that change as well. Georg
Re: Status on Mac with El Capitan
Le 09/01/16 23:01, Scott Kostyshak a écrit : I do not understand it. I'm fine as long as another developer gives an explicit +1. I see it is in now. It is fine for me. JMarc
Re: Status on Mac with El Capitan
Am Samstag, 9. Januar 2016 um 15:02:14, schrieb Kornel Benko > Am Samstag, 9. Januar 2016 um 14:27:46, schrieb Stephan Witt > > Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes : > > > > > > Le 08/01/2016 10:08, Stephan Witt a écrit : > > >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : > > >>> Yes, unless somone has a different brilliant idea. > > >> > > >> Am I right that it makes explicit what is otherwise implicit? So it is > > >> safe to commit? > > > > > > Yes, I think so. The question is only maintainability. Guillaume > > > complained that the is fragile because new code can forget to add this > > > explicit lyx::. > > > > Scott, > > > > I’d like to commit the patch (attached again). Is this ok? > > It applies cleanly, compiles on linux. First tests are OK. > > > Stephan > Meant +1 Kornel signature.asc Description: This is a digitally signed message part.
Re: Status on Mac with El Capitan
On Sat, Jan 09, 2016 at 02:27:46PM +0100, Stephan Witt wrote: > Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes : > > > > Le 08/01/2016 10:08, Stephan Witt a écrit : > >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : > >>> Yes, unless somone has a different brilliant idea. > >> > >> Am I right that it makes explicit what is otherwise implicit? So it is > >> safe to commit? > > > > Yes, I think so. The question is only maintainability. Guillaume complained > > that the is fragile because new code can forget to add this explicit lyx::. > > Scott, > > I’d like to commit the patch (attached again). Is this ok? I do not understand it. I'm fine as long as another developer gives an explicit +1. Scott signature.asc Description: PGP signature
Re: Status on Mac with El Capitan
Am Samstag, 9. Januar 2016 um 14:27:46, schrieb Stephan Witt > Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes : > > > > Le 08/01/2016 10:08, Stephan Witt a écrit : > >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : > >>> Yes, unless somone has a different brilliant idea. > >> > >> Am I right that it makes explicit what is otherwise implicit? So it is > >> safe to commit? > > > > Yes, I think so. The question is only maintainability. Guillaume complained > > that the is fragile because new code can forget to add this explicit lyx::. > > Scott, > > I’d like to commit the patch (attached again). Is this ok? It applies cleanly, compiles on linux. First tests are OK. > Stephan Kornel > > > >>> The problem is that libc++ provides std::next even when not in C++11 mode. > >> > >> Is the implementation of std::next compatible to the e.g. > >> ParagraphList::iterator or not? > > > > It should. The problem is only that we provide boost::next when not in > > C++11 mode, but clang already provides the real std::next. > > > > The proper fix would be to check at configure time whether std::next exists > > and react on that. But it is extra work :) > > > >>> This problem will go away in 2.3. > >> > >> How? With your fix? Does it fix wrong LyX code or is it some work around? > > > > Because support for c++98 will go away, together with many of our lyx:: > > wrappers. > > > > Georg, do you have a thought on that? signature.asc Description: This is a digitally signed message part.
Re: Status on Mac with El Capitan
Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes : > > Le 08/01/2016 10:08, Stephan Witt a écrit : >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : >>> Yes, unless somone has a different brilliant idea. >> >> Am I right that it makes explicit what is otherwise implicit? So it is safe >> to commit? > > Yes, I think so. The question is only maintainability. Guillaume complained > that the is fragile because new code can forget to add this explicit lyx::. Scott, I’d like to commit the patch (attached again). Is this ok? Stephan > >>> The problem is that libc++ provides std::next even when not in C++11 mode. >> >> Is the implementation of std::next compatible to the e.g. >> ParagraphList::iterator or not? > > It should. The problem is only that we provide boost::next when not in C++11 > mode, but clang already provides the real std::next. > > The proper fix would be to check at configure time whether std::next exists > and react on that. But it is extra work :) > >>> This problem will go away in 2.3. >> >> How? With your fix? Does it fix wrong LyX code or is it some work around? > > Because support for c++98 will go away, together with many of our lyx:: > wrappers. > > Georg, do you have a thought on that? lyx-iter-next-prev.patch Description: Binary data
Re: Status on Mac with El Capitan
Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes :Le 08/01/2016 10:08, Stephan Witt a écrit :Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes :Yes, unless somone has a different brilliant idea.Am I right that it makes explicit what is otherwise implicit? So it is safe to commit?Yes, I think so. The question is only maintainability. Guillaume complained that the is fragile because new code can forget to add this explicit lyx::.Scott,I’d like to commit the patch (attached again). Is this ok?StephanThe problem is that libc++ provides std::next even when not in C++11 mode.Is the implementation of std::next compatible to the e.g. ParagraphList::iterator or not?It should. The problem is only that we provide boost::next when not in C++11 mode, but clang already provides the real std::next.The proper fix would be to check at configure time whether std::next exists and react on that. But it is extra work :)This problem will go away in 2.3.How? With your fix? Does it fix wrong LyX code or is it some work around?Because support for c++98 will go away, together with many of our lyx:: wrappers.Georg, do you have a thought on that? lyx-iter-next-prev.patch Description: Binary data
Re: Status on Mac with El Capitan
Am 09.01.2016 um 13:12 schrieb Stephan Witt:
Am 08.01.2016 um 13:15 schrieb Kornel Benko :
Am Freitag, 8. Januar 2016 um 13:09:38, schrieb Stephan Witt
Am 08.01.2016 um 11:53 schrieb Kornel Benko :
Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt
OR (maybe)
include_directories((BEFORE
${TOP_SRC_DIR}/src/tex2lyx
${TOP_SRC_DIR}/src/support/minizip)
include_directories(${ZLIB_INCLUDE_DIR})
Yes, this works too. BTW, what is "src/support/minizip“ for?
It doesn’t exist in the master checkout.
Why should "src/tex2lyx“ come before other includes?
Stephan
I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.
Yes, but what’s the gain of having "src/tex2lyx“ before other includes?
Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing
it.
Peter, is the attached patch ok?
Removing the minizip should make no problems.
Stephan
I wanted to change as little as possible.
The removal of the BEFORE keyword did the job too.
Sure.
Re: Status on Mac with El Capitan
Am 08.01.2016 um 13:15 schrieb Kornel Benko :
>
> Am Freitag, 8. Januar 2016 um 13:09:38, schrieb Stephan Witt
>> Am 08.01.2016 um 11:53 schrieb Kornel Benko :
>>>
>>> Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt
>>>
> OR (maybe)
> include_directories((BEFORE
> ${TOP_SRC_DIR}/src/tex2lyx
> ${TOP_SRC_DIR}/src/support/minizip)
> include_directories(${ZLIB_INCLUDE_DIR})
Yes, this works too. BTW, what is "src/support/minizip“ for?
It doesn’t exist in the master checkout.
Why should "src/tex2lyx“ come before other includes?
Stephan
>>>
>>> I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.
>>
>> Yes, but what’s the gain of having "src/tex2lyx“ before other includes?
>
> Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing
> it.
Peter, is the attached patch ok?
Stephan
> I wanted to change as little as possible.
>
>> The removal of the BEFORE keyword did the job too.
>
> Sure.
tex2lyx-cmake.patch
Description: Binary data
Re: Status on Mac with El Capitan
Am Freitag, 8. Januar 2016 um 13:09:38, schrieb Stephan Witt
> Am 08.01.2016 um 11:53 schrieb Kornel Benko :
> >
> > Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt
> >
> >>> OR (maybe)
> >>> include_directories((BEFORE
> >>>${TOP_SRC_DIR}/src/tex2lyx
> >>>${TOP_SRC_DIR}/src/support/minizip)
> >>> include_directories(${ZLIB_INCLUDE_DIR})
> >>
> >> Yes, this works too. BTW, what is "src/support/minizip“ for?
> >> It doesn’t exist in the master checkout.
> >> Why should "src/tex2lyx“ come before other includes?
> >>
> >> Stephan
> >
> > I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.
>
> Yes, but what’s the gain of having "src/tex2lyx“ before other includes?
Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing
it.
I wanted to change as little as possible.
> The removal of the BEFORE keyword did the job too.
Sure.
> Stephan
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: Status on Mac with El Capitan
Am 08.01.2016 um 11:53 schrieb Kornel Benko :
>
> Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt
>>> OR (maybe)
>>> include_directories((BEFORE
>>>${TOP_SRC_DIR}/src/tex2lyx
>>>${TOP_SRC_DIR}/src/support/minizip)
>>> include_directories(${ZLIB_INCLUDE_DIR})
>>
>> Yes, this works too. BTW, what is "src/support/minizip“ for?
>> It doesn’t exist in the master checkout.
>> Why should "src/tex2lyx“ come before other includes?
>>
>> Stephan
>
> I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.
Yes, but what’s the gain of having "src/tex2lyx“ before other includes?
The removal of the BEFORE keyword did the job too.
Stephan
Re: Status on Mac with El Capitan
Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt
> > OR (maybe)
> > include_directories((BEFORE
> > ${TOP_SRC_DIR}/src/tex2lyx
> > ${TOP_SRC_DIR}/src/support/minizip)
> > include_directories(${ZLIB_INCLUDE_DIR})
>
> Yes, this works too. BTW, what is "src/support/minizip“ for?
> It doesn’t exist in the master checkout.
> Why should "src/tex2lyx“ come before other includes?
>
> Stephan
I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include".
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: Status on Mac with El Capitan
Le 08/01/2016 10:08, Stephan Witt a écrit : Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : Yes, unless somone has a different brilliant idea. Am I right that it makes explicit what is otherwise implicit? So it is safe to commit? Yes, I think so. The question is only maintainability. Guillaume complained that the is fragile because new code can forget to add this explicit lyx::. The problem is that libc++ provides std::next even when not in C++11 mode. Is the implementation of std::next compatible to the e.g. ParagraphList::iterator or not? It should. The problem is only that we provide boost::next when not in C++11 mode, but clang already provides the real std::next. The proper fix would be to check at configure time whether std::next exists and react on that. But it is extra work :) This problem will go away in 2.3. How? With your fix? Does it fix wrong LyX code or is it some work around? Because support for c++98 will go away, together with many of our lyx:: wrappers. Georg, do you have a thought on that? JMarc
Re: Status on Mac with El Capitan
Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : > > Le 08/01/2016 09:17, Stephan Witt a écrit : >> A possible solution I’ve attached as patch. >> Any better solution or ok to commit? > > Yes, unless somone has a different brilliant idea. Am I right that it makes explicit what is otherwise implicit? So it is safe to commit? > The problem is that libc++ provides std::next even when not in C++11 mode. Is the implementation of std::next compatible to the e.g. ParagraphList::iterator or not? > > This problem will go away in 2.3. How? With your fix? Does it fix wrong LyX code or is it some work around? Stephan > > JMarc > > PS: I have a fix for your compilation problem in C++11 mode (libc++ bug) >
Re: Status on Mac with El Capitan
Le 08/01/2016 09:17, Stephan Witt a écrit : A possible solution I’ve attached as patch. Any better solution or ok to commit? Yes, unless somone has a different brilliant idea. The problem is that libc++ provides std::next even when not in C++11 mode. This problem will go away in 2.3. JMarc PS: I have a fix for your compilation problem in C++11 mode (libc++ bug)
Re: Status on Mac with El Capitan
Am 07.01.2016 um 15:39 schrieb Stephan Witt : > ... > The next problem now is an error when compiling src/Compare.cpp: > > Stephan > > === > CompileC > /Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.o > src/Compare.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler >cd /Users/stephan/git/lyx >export LANG=en_US.US-ASCII > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang > -x c++ -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack > -fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O0 > -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type > -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors > -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function > -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value > -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow > -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion > -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion > -Wno-shorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions > -DCMAKE_INTDIR=\"Debug\" -DQT_CORE_LIB -DQT_GUI_LIB > -DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DQT_WIDGETS_LIB -DQT_CONCURRENT_LIB > -DQT_SVG_LIB -DQT_MACEXTRAS_LIB -isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk > -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof > -mmacosx-version-min=10.11 -g -Wno-sign-conversion > -I/Users/stephan/git/lyx-build/cmake/2.2.0dev/bin/Debug/include > -I/Users/stephan/git/lyx-build/cmake/2.2.0dev -I/Users/stephan/git/lyx/src > -I/Users/Shared/LyX/utilities/include -I/Users/stephan/git/lyx/3rdparty/boost > -I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src -I/opt/local/include > -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtCore.framework/Headers > -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/mkspecs/macx-clang > -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtGui.framework/Headers > > -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Headers > > -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtWidgets.framework/Headers > > -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtConcurrent.framework/Headers > > -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtSvg.framework/Headers > > -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtMacExtras.framework/Headers > > -I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/DerivedSources/x86_64 > > -I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/DerivedSources > -Wmost -Wno-four-char-constants -Wno-unknown-pragmas > -F/Users/stephan/git/lyx-build/cmake/2.2.0dev/bin/Debug > -F/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib -Wall > -Wunused-parameter -fno-strict-aliasing -Wall -Wunused-parameter > -fno-strict-aliasing -D_DEBUG -fPIC -DBOOST_USER_CONFIG= -MMD -MT > dependencies -MF > /Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.d > --serialize-diagnostics > /Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.dia > -c /Users/stephan/git/lyx/src/Compare.cpp -o > /Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.o > > /Users/stephan/git/lyx/src/Compare.cpp:425:25: error: call to 'next' is > ambiguous >ParagraphList tmp_pars(next(ps_.begin(), startpit), > ^~~~ > In file included from /Users/stephan/git/lyx/src/Compare.cpp:13: > In file included from /Users/stephan/git/lyx/src/Compare.h:15: > In file included from /Users/stephan/git/lyx/src/Buffer.h:16: > In file included from /Users/stephan/git/lyx/src/OutputParams.h:16: > In file included from /Users/stephan/git/lyx/src/support/shared_ptr.h:22: > In file included from > /Users/stephan/git/lyx/3rdparty/boost/boost/shared_ptr.hpp:17: > In file included from > /Users/stephan/git/lyx/3rdparty/boost/boost/smart_ptr/shared_ptr.hpp:23: > In file included from > /Users/stephan/git/lyx/3rdparty/boost/boost/config/no_tr1/memory.hpp:21: > In file included from > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:604: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iterator:519:1: > note: candidate function [with _ForwardIter = > std::__1::__list_const_iterator] > next(_ForwardIter __x, > ^ > In file included from /Users/stephan/git/lyx/src/Compare.cpp:23: > /Users/stephan/git/lyx/src/support/lyxalgo.h:92:11: note: candidate function >
Re: Status on Mac with El Capitan
> Am 07.01.2016 um 16:00 schrieb Kornel Benko :
>
> Am Donnerstag, 7. Januar 2016 um 15:39:47, schrieb Stephan Witt
>
>> Am 07.01.2016 um 14:51 schrieb Kornel Benko :
>>>
>>> Am Donnerstag, 7. Januar 2016 um 14:30:58, schrieb Stephan Witt
>>>
The position of -I/opt/local/linclude in front of
-I/Users/stephan/git/lyx/3rdparty/boost is the problem.
I wrote this in my previous mail.
>>>
>>> This should be easy
>>>
>>> in CMakeLists.txt:738
>>> substitute
>>> include_directories(${TOP_SRC_DIR}/3rdparty/boost)
>>> with
>>> include_directories(BEFORE ${TOP_SRC_DIR}/3rdparty/boost)
>>> or even
>>> include_directories(BEFORE SYSTEM ${TOP_SRC_DIR}/3rdparty/boost)
>>
>> It didn’t help.
>>
>> The following (inline) patch helps to build tex2lyx:
>>
>> diff --git a/src/tex2lyx/CMakeLists.txt b/src/tex2lyx/CMakeLists.txt
>> index 09bcc2b..f4a9841 100644
>> --- a/src/tex2lyx/CMakeLists.txt
>> +++ b/src/tex2lyx/CMakeLists.txt
>> @@ -24,7 +24,7 @@ file(GLOB tex2lyx_sources
>> ${TOP_SRC_DIR}/src/tex2lyx/${LYX_CPP_FILES})
>>
>> file(GLOB tex2lyx_headers ${TOP_SRC_DIR}/src/tex2lyx/${LYX_HPP_FILES})
>>
>> -include_directories(BEFORE
>> +include_directories(
>>${TOP_SRC_DIR}/src/tex2lyx
>>${TOP_SRC_DIR}/src/support/minizip
>>${ZLIB_INCLUDE_DIR})
>
> OR (maybe)
> include_directories((BEFORE
> ${TOP_SRC_DIR}/src/tex2lyx
> ${TOP_SRC_DIR}/src/support/minizip)
> include_directories(${ZLIB_INCLUDE_DIR})
Yes, this works too. BTW, what is "src/support/minizip“ for?
It doesn’t exist in the master checkout.
Why should "src/tex2lyx“ come before other includes?
Stephan
>
> Cannot help on next(...)
>
> Kornel
Re: Status on Mac with El Capitan
Am 07.01.2016 um 14:51 schrieb Kornel Benko :
>
> Am Donnerstag, 7. Januar 2016 um 14:30:58, schrieb Stephan Witt
>
>> The position of -I/opt/local/linclude in front of
>> -I/Users/stephan/git/lyx/3rdparty/boost is the problem.
>> I wrote this in my previous mail.
>
> This should be easy
>
> in CMakeLists.txt:738
> substitute
> include_directories(${TOP_SRC_DIR}/3rdparty/boost)
> with
> include_directories(BEFORE ${TOP_SRC_DIR}/3rdparty/boost)
> or even
> include_directories(BEFORE SYSTEM ${TOP_SRC_DIR}/3rdparty/boost)
It didn’t help.
The following (inline) patch helps to build tex2lyx:
diff --git a/src/tex2lyx/CMakeLists.txt b/src/tex2lyx/CMakeLists.txt
index 09bcc2b..f4a9841 100644
--- a/src/tex2lyx/CMakeLists.txt
+++ b/src/tex2lyx/CMakeLists.txt
@@ -24,7 +24,7 @@ file(GLOB tex2lyx_sources
${TOP_SRC_DIR}/src/tex2lyx/${LYX_CPP_FILES})
file(GLOB tex2lyx_headers ${TOP_SRC_DIR}/src/tex2lyx/${LYX_HPP_FILES})
-include_directories(BEFORE
+include_directories(
${TOP_SRC_DIR}/src/tex2lyx
${TOP_SRC_DIR}/src/support/minizip
${ZLIB_INCLUDE_DIR})
The next problem now is an error when compiling src/Compare.cpp:
Stephan
===
CompileC
/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.o
src/Compare.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/stephan/git/lyx
export LANG=en_US.US-ASCII
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-x c++ -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack
-fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O0
-Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type
-Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors
-Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function
-Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value
-Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow
-Wno-four-char-constants -Wno-conversion -Wno-constant-conversion
-Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion
-Wno-shorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions
-DCMAKE_INTDIR=\"Debug\" -DQT_CORE_LIB -DQT_GUI_LIB
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DQT_WIDGETS_LIB -DQT_CONCURRENT_LIB
-DQT_SVG_LIB -DQT_MACEXTRAS_LIB -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
-fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof
-mmacosx-version-min=10.11 -g -Wno-sign-conversion
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev/bin/Debug/include
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev -I/Users/stephan/git/lyx/src
-I/Users/Shared/LyX/utilities/include -I/Users/stephan/git/lyx/3rdparty/boost
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src -I/opt/local/include
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtCore.framework/Headers
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/mkspecs/macx-clang
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtGui.framework/Headers
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Headers
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtWidgets.framework/Headers
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtConcurrent.framework/Headers
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtSvg.framework/Headers
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtMacExtras.framework/Headers
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/DerivedSources/x86_64
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/DerivedSources
-Wmost -Wno-four-char-constants -Wno-unknown-pragmas
-F/Users/stephan/git/lyx-build/cmake/2.2.0dev/bin/Debug
-F/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib -Wall
-Wunused-parameter -fno-strict-aliasing -Wall -Wunused-parameter
-fno-strict-aliasing -D_DEBUG -fPIC -DBOOST_USER_CONFIG= -MMD -MT
dependencies -MF
/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.d
--serialize-diagnostics
/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.dia
-c /Users/stephan/git/lyx/src/Compare.cpp -o
/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.o
/Users/stephan/git/lyx/src/Compare.cpp:425:25: error: call to 'next' is
ambiguous
ParagraphList tmp_pars(next(ps_.begin(), startpit),
^~~~
In file included from /Users/stephan/git/lyx/src/Compare.cpp:13:
In file included from /Users/stephan/git/lyx/src/Compare.h:15:
In file included from /Users/stephan/git/lyx/src/Buffer.h:16:
In file included from /Users/stephan/g
Re: Status on Mac with El Capitan
Stefan, are you sure using clean build-dir? At least CMakeCache.txt may contain some include paths from previous run. For instance changing -DLYX_EXTERNAL_BOOST=.. without removing CMakeCache.txt is asking for trouble IMHO. Am Donnerstag, 7. Januar 2016 um 13:46:42, schrieb Stephan Witt > Am 07.01.2016 um 11:01 schrieb Kornel Benko : > > > > Am Mittwoch, 6. Januar 2016 um 11:39:10, schrieb Jean-Marc Lasgouttes > > > >> Le 06/01/2016 11:09, Kornel Benko a écrit : > It would be nice if we could converge to the same algorithm in the two > build systems. If you disagree on what autotools do, we can discuss > adaptations. > >>> > >>> In cmake it is an option, which is set _before_ we know the compiler. > >> > >> Actually it is the same in autotools, but the default value is "auto" > >> > >>> I could change it for UNIX (with clang | gnu-c++) or MINGW, but I am not > >>> confident enough to change it for MSVC. > >> > >> It would be a very good way to din out. People can always override it if > >> the default is not correct... > >> > >> JMarc > > > > The attached works for me. Cmake-gui looks good, deafault for > > LYX_ENABLE_CXX11 is string "AUTO". > > > > Starting with empty CMakeCache.txt the variable LYX_ENABLE_CXX11 is saved > > as of type STRING. > > Using already used (created before the patch) CMakeCache.txt it is saved as > > of type BOOL. Although this > > is now wrong, it still works. One only cannot select "AUTO" in the > > cmake-gui. > > > > Kornel > > With the patch CXX11_FLAG_DETECTED works but is reported twice to console. > > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done Yes, I had to duplicate the code to be used for "AUTO"-case too. This happens only on first cmake run though. > -- CXX11_FLAG_DETECTED = "--std=c++11 -Wno-deprecated-register" > -- Found CXX11Compiler: --std=c++11 -Wno-deprecated-register > -- Using GCC version 4.2.1 > -- CXX11_FLAG_DETECTED = "--std=c++11 -Wno-deprecated-register" > -- Found Qt-Version 5.4.2 > -- Looking for magic_file > -- Looking for magic_file - found > > On my Mac with latest El Capitan the resulting Xcode project is > not usable because of an compiler error: > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2075:40: > Constructor for > 'std::__1::__libcpp_compressed_pair_imp, > const lyx::Toc, 1>' must explicitly initialize the const member '__second_' > > I cannot tell if this is a compiler bug but is seems so. > > Alternatively I can disable CXX11 with -DLYX_ENABLE_CXX11=OFF. > Then I’m back to the linker problem because of the conflicting > versions of the system (external) and the LyX 3rdparty boost. > > The error message are like this: > > Undefined symbols for architecture x86_64: > "boost::re_detail::get_mem_block()", referenced from: > > boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**, > boost::re_detail::saved_state**) in LayoutFile.o > boost::re_detail::perl_matcher, > std::__1::allocator > >, > boost::regex_traits > >::extend_stack() > in LayoutFile.o > > boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**, > boost::re_detail::saved_state**) in ExternalTransforms.o > boost::re_detail::perl_matcher, > std::__1::allocator > >, > boost::regex_traits > >::extend_stack() > in ExternalTransforms.o > boost::re_detail::perl_matcher, > std::__1::allocator > >, > boost::regex_traits > >::extend_stack() > in Preamble.o > > boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**, > boost::re_detail::saved_state**) in Preamble.o This is linking for lyx I suppose? Could you post the linker line # make VERBOSE=1 lyx or/and try to find the correct link command manually? Maybe compare with autotools make output? > If I add -DLYX_EXTERNAL_BOOST=ON the build stops with this error: > > In file included from > /Users/stephan/git/lyx/src/insets/ExternalTemplate.cpp:14: > In file included from /Users/stephan/git/lyx/src/insets/ExternalTemplate.h:16: > /Users/stephan/git/lyx/src/insets/ExternalTransforms.h:19:10: fatal error: > 'boost/any.hpp' file not found > #include > ^ > 1 error generated. > > The question is now: why does it work on the same system with auto tools? > Probably it works because of using LyX internal boost and passing the > proper include locations to the compiler calls. See what I wrote at begin of this mail. > ATM, cmake passes the include locations that way: > > -I/Users/stephan/git/lyx-build/cmake/2.2.0dev/bin/Debug/include > -I/opt/local/include > -I/Users/stephan/git/lyx/src/support/minizip > -I/Users/stephan/git/lyx/src/tex2lyx > -I/Users/stephan/git/lyx-build/cmake/2.2.0dev > -I/Users/stephan/git/lyx/src > -I/Users/Shared/LyX/utilities/include > -I
Re: Status on Mac with El Capitan
Am 07.01.2016 um 11:01 schrieb Kornel Benko : > > Am Mittwoch, 6. Januar 2016 um 11:39:10, schrieb Jean-Marc Lasgouttes > >> Le 06/01/2016 11:09, Kornel Benko a écrit : It would be nice if we could converge to the same algorithm in the two build systems. If you disagree on what autotools do, we can discuss adaptations. >>> >>> In cmake it is an option, which is set _before_ we know the compiler. >> >> Actually it is the same in autotools, but the default value is "auto" :) >> >>> I could change it for UNIX (with clang | gnu-c++) or MINGW, but I am not >>> confident enough to change it for MSVC. >> >> It would be a very good way to din out. People can always override it if >> the default is not correct... >> >> JMarc > > The attached works for me. Cmake-gui looks good, deafault for > LYX_ENABLE_CXX11 is string "AUTO". > > Starting with empty CMakeCache.txt the variable LYX_ENABLE_CXX11 is saved as > of type STRING. > Using already used (created before the patch) CMakeCache.txt it is saved as > of type BOOL. Although this > is now wrong, it still works. One only cannot select "AUTO" in the cmake-gui. > > Kornel With the patch CXX11_FLAG_DETECTED works but is reported twice to console. -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- -- CXX11_FLAG_DETECTED = "--std=c++11 -Wno-deprecated-register" -- Found CXX11Compiler: --std=c++11 -Wno-deprecated-register -- Using GCC version 4.2.1 -- CXX11_FLAG_DETECTED = "--std=c++11 -Wno-deprecated-register" -- Found Qt-Version 5.4.2 -- Looking for magic_file -- Looking for magic_file - found On my Mac with latest El Capitan the resulting Xcode project is not usable because of an compiler error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2075:40: Constructor for 'std::__1::__libcpp_compressed_pair_imp, const lyx::Toc, 1>' must explicitly initialize the const member '__second_' I cannot tell if this is a compiler bug but is seems so. Alternatively I can disable CXX11 with -DLYX_ENABLE_CXX11=OFF. Then I’m back to the linker problem because of the conflicting versions of the system (external) and the LyX 3rdparty boost. The error message are like this: Undefined symbols for architecture x86_64: "boost::re_detail::get_mem_block()", referenced from: boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**, boost::re_detail::saved_state**) in LayoutFile.o boost::re_detail::perl_matcher, std::__1::allocator > >, boost::regex_traits > >::extend_stack() in LayoutFile.o boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**, boost::re_detail::saved_state**) in ExternalTransforms.o boost::re_detail::perl_matcher, std::__1::allocator > >, boost::regex_traits > >::extend_stack() in ExternalTransforms.o boost::re_detail::perl_matcher, std::__1::allocator > >, boost::regex_traits > >::extend_stack() in Preamble.o boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**, boost::re_detail::saved_state**) in Preamble.o If I add -DLYX_EXTERNAL_BOOST=ON the build stops with this error: In file included from /Users/stephan/git/lyx/src/insets/ExternalTemplate.cpp:14: In file included from /Users/stephan/git/lyx/src/insets/ExternalTemplate.h:16: /Users/stephan/git/lyx/src/insets/ExternalTransforms.h:19:10: fatal error: 'boost/any.hpp' file not found #include ^ 1 error generated. The question is now: why does it work on the same system with auto tools? Probably it works because of using LyX internal boost and passing the proper include locations to the compiler calls. ATM, cmake passes the include locations that way: -I/Users/stephan/git/lyx-build/cmake/2.2.0dev/bin/Debug/include -I/opt/local/include -I/Users/stephan/git/lyx/src/support/minizip -I/Users/stephan/git/lyx/src/tex2lyx -I/Users/stephan/git/lyx-build/cmake/2.2.0dev -I/Users/stephan/git/lyx/src -I/Users/Shared/LyX/utilities/include -I/Users/stephan/git/lyx/3rdparty/boost -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtCore.framework/Headers -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/mkspecs/macx-clang -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtGui.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/tex2lyx/LyX.build/Debug/tex2lyx.build/DerivedSources/x86_64 -I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/tex2lyx/LyX.build/Debug/tex2lyx.build/DerivedSources The -I/opt/local/include directive points to the external boost library. That way external boost is preferred by the compiler with setting -DLYX_EXTERNAL_BOOST=OFF - obviously this is not correct. Perhaps it is cau
Re: Status on Mac with El Capitan
Am Mittwoch, 6. Januar 2016 um 11:39:10, schrieb Jean-Marc Lasgouttes
> Le 06/01/2016 11:09, Kornel Benko a écrit :
> >> It would be nice if we could converge to the same algorithm in the two
> >> build systems. If you disagree on what autotools do, we can discuss
> >> adaptations.
> >
> > In cmake it is an option, which is set _before_ we know the compiler.
>
> Actually it is the same in autotools, but the default value is "auto" :)
>
> > I could change it for UNIX (with clang | gnu-c++) or MINGW, but I am not
> > confident enough to change it for MSVC.
>
> It would be a very good way to din out. People can always override it if
> the default is not correct...
>
> JMarc
The attached works for me. Cmake-gui looks good, deafault for LYX_ENABLE_CXX11
is string "AUTO".
Starting with empty CMakeCache.txt the variable LYX_ENABLE_CXX11 is saved as of
type STRING.
Using already used (created before the patch) CMakeCache.txt it is saved as of
type BOOL. Although this
is now wrong, it still works. One only cannot select "AUTO" in the cmake-gui.
Kornel
signature.asc
Description: This is a digitally signed message part.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f657fd5..ce35a53 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -140,6 +140,7 @@ LYX_OPTION(ENABLE_EXPORT_TESTS "Enable for export tests" OFF ALL)
LYX_OPTION(ASAN "Use address sanitizer" OFF ALL)
LYX_COMBO(USE_QT"Use Qt version as frontend" QT4 QT5)
LYX_OPTION(3RDPARTY_BUILD "Build 3rdparty libs" OFF ALL)
+LYX_COMBO(ENABLE_CXX11 "Build with options for c++11-mode" AUTO ON OFF)
# GCC specific
LYX_OPTION(PROFILE "Build profile version" OFF GCC)
@@ -149,7 +150,6 @@ LYX_OPTION(DEBUG_GLIBC "Enable libstdc++ debug mode" OFF GCC)
LYX_OPTION(DEBUG_GLIBC_PEDANTIC "Enable libstdc++ pedantic debug mode" OFF GCC)
LYX_OPTION(STDLIB_DEBUG "Use debug stdlib" OFF GCC)
LYX_OPTION(PROFILE "Build with options for gprof" OFF GCC)
-LYX_OPTION(ENABLE_CXX11 "Build with options for c++11-mode" OFF GCC)
# MSVC specific
LYX_OPTION(CONSOLE "Show console on Windows, enforce with =FORCE" ON MSVC)
@@ -251,7 +251,29 @@ else()
set(LIBRARY_OUTPUT_PATH ${TOP_BINARY_DIR}/lib)
endif()
-
+if(LYX_ENABLE_CXX11 MATCHES "AUTO")
+ # Set to some meaningful default
+ find_package(CXX11Compiler)
+ if(NOT CXX11COMPILER_FOUND)
+set(LYX_ENABLE_CXX11 OFF CACHE TYPE STRING FORCE)
+ else()
+if(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
+ execute_process(COMMAND ${CMAKE_CXX_COMPILER} -dumpversion OUTPUT_VARIABLE GCC_VERSION OUTPUT_STRIP_TRAILING_WHITESPACE)
+ if(NOT GCC_VERSION VERSION_LESS 4.3)
+set(LYX_ENABLE_CXX11 ON CACHE TYPE STRING FORCE)
+ else()
+set(LYX_ENABLE_CXX11 OFF CACHE TYPE STRING FORCE)
+ endif()
+else()
+ # Not a gnu compiler
+ if(CMAKE_CXX_COMPILER_ID MATCHES "^[cC]lang$")
+set(LYX_ENABLE_CXX11 ON CACHE TYPE STRING FORCE)
+ else()
+set(LYX_ENABLE_CXX11 OFF CACHE TYPE STRING FORCE)
+ endif()
+endif()
+ endif()
+endif()
set(LYX_GCC11_MODE)
if(UNIX OR MINGW)
execute_process(COMMAND ${CMAKE_CXX_COMPILER} -dumpversion OUTPUT_VARIABLE GCC_VERSION OUTPUT_STRIP_TRAILING_WHITESPACE)
Re: Status on Mac with El Capitan
Le 06/01/2016 11:09, Kornel Benko a écrit : It would be nice if we could converge to the same algorithm in the two build systems. If you disagree on what autotools do, we can discuss adaptations. In cmake it is an option, which is set _before_ we know the compiler. Actually it is the same in autotools, but the default value is "auto" :) I could change it for UNIX (with clang | gnu-c++) or MINGW, but I am not confident enough to change it for MSVC. It would be a very good way to din out. People can always override it if the default is not correct... JMarc
Re: Status on Mac with El Capitan
Am Mittwoch, 6. Januar 2016 um 10:26:24, schrieb Jean-Marc Lasgouttes > Le 05/01/2016 18:04, Kornel Benko a écrit : > >> Isn't LYX_ENABLE_CXX11=ON the default for clang? > > > > By default it is OFF for any compiler. > > > >> I have to use —-disable-cxx11 with auto tools. > >> Why is it working with cmake for you? > >> Where is your Qt5 framework? > >> What compiler are you using? > > Kornel, it would be nice to enable C++11 by default when possible in > 2.2. In 2.3 we will make it a requirement. This probably means that we > have to find out how to do that with msvc and make sure that it works. > > For reference the algorithm used by autotools for 2.2 is the following: > > * enable c++11 by default for gcc >= 4.3 and all real clang (not the > older gcc based one) >For clang, also use -Wno-deprecated-register (lots of warnings with Qt4) > * when forcing c++11 on gcc <= 4.2, error out. > * if using gcc under cygwin use mode gnu++11 instead of c++11 > > Separately, detect that c++11 is enabled by testing for > __cplusplus >= 201103L || defined(__GXX_EXPERIMENTAL_CXX0X__) > > We do the test separately so that people can use a compiler we do not > handle and set it manually in c++11 mode. > > When c++11 mode is detected > * define LYX_USE_CXX11 > * add flag -Wno-deprecated-declarations, so that we do not get warnings > about the deprecated auto_ptr (we will remove this in 2.3) > * define LYX_USE_STD_REGEX when using C++11 with either clang or gcc >= > 4.9. [although there is something fishy with the current code that I > have to double check]. > > > It would be nice if we could converge to the same algorithm in the two > build systems. If you disagree on what autotools do, we can discuss > adaptations. In cmake it is an option, which is set _before_ we know the compiler. I could change it for UNIX (with clang | gnu-c++) or MINGW, but I am not confident enough to change it for MSVC. > JMarc Kornel signature.asc Description: This is a digitally signed message part.
Re: Status on Mac with El Capitan
Le 05/01/2016 18:04, Kornel Benko a écrit : Isn't LYX_ENABLE_CXX11=ON the default for clang? By default it is OFF for any compiler. I have to use —-disable-cxx11 with auto tools. Why is it working with cmake for you? Where is your Qt5 framework? What compiler are you using? Kornel, it would be nice to enable C++11 by default when possible in 2.2. In 2.3 we will make it a requirement. This probably means that we have to find out how to do that with msvc and make sure that it works. For reference the algorithm used by autotools for 2.2 is the following: * enable c++11 by default for gcc >= 4.3 and all real clang (not the older gcc based one) For clang, also use -Wno-deprecated-register (lots of warnings with Qt4) * when forcing c++11 on gcc <= 4.2, error out. * if using gcc under cygwin use mode gnu++11 instead of c++11 Separately, detect that c++11 is enabled by testing for __cplusplus >= 201103L || defined(__GXX_EXPERIMENTAL_CXX0X__) We do the test separately so that people can use a compiler we do not handle and set it manually in c++11 mode. When c++11 mode is detected * define LYX_USE_CXX11 * add flag -Wno-deprecated-declarations, so that we do not get warnings about the deprecated auto_ptr (we will remove this in 2.3) * define LYX_USE_STD_REGEX when using C++11 with either clang or gcc >= 4.9. [although there is something fishy with the current code that I have to double check]. It would be nice if we could converge to the same algorithm in the two build systems. If you disagree on what autotools do, we can discuss adaptations. JMarc
Re: Status on Mac with El Capitan
Am 05.01.2016 um 18:20 schrieb Stephan Witt : > > Am 05.01.2016 um 18:04 schrieb Kornel Benko : >> >> Am Dienstag, 5. Januar 2016 um 17:59:10, schrieb Stephan Witt >> >>> Am 05.01.2016 um 15:07 schrieb Edwin Leuven : On 05 Jan 2016, at 02:13, Stephan Witt wrote: > Hi Lyxers, > > it’s a long overdue task I had on my ToDo list: > the update of my system to latest OS X - El Capitan. > > It’s accompanied by an update of many components including the > development tools, the compiler, the IDE, etc. > > The situation after doing so is as follows: > > 2. The build with cmake is broken in two different ways i can build with cmake ../lyx -DLYX_USE_QT=QT5 -DLYX_ENABLE_CXX11=ON -GXcode >>> >>> Sorry, I don’t understand. >>> >>> You’re on Mac OS X 10.11 too? >>> Isn't LYX_ENABLE_CXX11=ON the default for clang? >> >> By default it is OFF for any compiler. > > Ok, it’s cached then. I see. > >> >>> I have to use —-disable-cxx11 with auto tools. >>> Why is it working with cmake for you? >>> Where is your Qt5 framework? >>> What compiler are you using? > > I’ve noticed now that I’ve installed the boost library in /opt/local. > > Perhaps the cmake (installed in /opt/local) generates a project file > where sometimes these headers are used? > > How can I check this? To answer myself: $ nm -g /opt/local/lib/libboost_regex-mt.dylib | grep get_mem_block 0006d170 T __ZN5boost9re_detail13get_mem_blockEv Ok, the project compiles private boost libraries but probably it doesn’t provide the include directory directives to prefer the private boost header files. How can one fix this? Stephan
Re: Status on Mac with El Capitan
Am 05.01.2016 um 18:04 schrieb Kornel Benko : > > Am Dienstag, 5. Januar 2016 um 17:59:10, schrieb Stephan Witt > >> Am 05.01.2016 um 15:07 schrieb Edwin Leuven : >>> >>> On 05 Jan 2016, at 02:13, Stephan Witt wrote: Hi Lyxers, it’s a long overdue task I had on my ToDo list: the update of my system to latest OS X - El Capitan. It’s accompanied by an update of many components including the development tools, the compiler, the IDE, etc. The situation after doing so is as follows: 2. The build with cmake is broken in two different ways >>> >>> i can build with >>> >>> cmake ../lyx -DLYX_USE_QT=QT5 -DLYX_ENABLE_CXX11=ON -GXcode >> >> Sorry, I don’t understand. >> >> You’re on Mac OS X 10.11 too? >> Isn't LYX_ENABLE_CXX11=ON the default for clang? > > By default it is OFF for any compiler. Ok, it’s cached then. I see. > >> I have to use —-disable-cxx11 with auto tools. >> Why is it working with cmake for you? >> Where is your Qt5 framework? >> What compiler are you using? I’ve noticed now that I’ve installed the boost library in /opt/local. Perhaps the cmake (installed in /opt/local) generates a project file where sometimes these headers are used? How can I check this? Stepgan
Re: Status on Mac with El Capitan
Am Dienstag, 5. Januar 2016 um 17:59:10, schrieb Stephan Witt > Am 05.01.2016 um 15:07 schrieb Edwin Leuven : > > > > On 05 Jan 2016, at 02:13, Stephan Witt wrote: > >> Hi Lyxers, > >> > >> it’s a long overdue task I had on my ToDo list: > >> the update of my system to latest OS X - El Capitan. > >> > >> It’s accompanied by an update of many components including the > >> development tools, the compiler, the IDE, etc. > >> > >> The situation after doing so is as follows: > >> > >> 2. The build with cmake is broken in two different ways > > > > i can build with > > > > cmake ../lyx -DLYX_USE_QT=QT5 -DLYX_ENABLE_CXX11=ON -GXcode > > Sorry, I don’t understand. > > You’re on Mac OS X 10.11 too? > Isn't LYX_ENABLE_CXX11=ON the default for clang? By default it is OFF for any compiler. > I have to use —-disable-cxx11 with auto tools. > Why is it working with cmake for you? > Where is your Qt5 framework? > What compiler are you using? > > Stephan Kornel signature.asc Description: This is a digitally signed message part.
Re: Status on Mac with El Capitan
Am 05.01.2016 um 15:07 schrieb Edwin Leuven : > > On 05 Jan 2016, at 02:13, Stephan Witt wrote: >> Hi Lyxers, >> >> it’s a long overdue task I had on my ToDo list: >> the update of my system to latest OS X - El Capitan. >> >> It’s accompanied by an update of many components including the >> development tools, the compiler, the IDE, etc. >> >> The situation after doing so is as follows: >> >> 2. The build with cmake is broken in two different ways > > i can build with > > cmake ../lyx -DLYX_USE_QT=QT5 -DLYX_ENABLE_CXX11=ON -GXcode Sorry, I don’t understand. You’re on Mac OS X 10.11 too? Isn't LYX_ENABLE_CXX11=ON the default for clang? I have to use —-disable-cxx11 with auto tools. Why is it working with cmake for you? Where is your Qt5 framework? What compiler are you using? Stephan
Re: Status on Mac with El Capitan
On 05 Jan 2016, at 02:13, Stephan Witt wrote: > Hi Lyxers, > > it’s a long overdue task I had on my ToDo list: > the update of my system to latest OS X - El Capitan. > > It’s accompanied by an update of many components including the > development tools, the compiler, the IDE, etc. > > The situation after doing so is as follows: > > 2. The build with cmake is broken in two different ways i can build with cmake ../lyx -DLYX_USE_QT=QT5 -DLYX_ENABLE_CXX11=ON -GXcode
