Am 07.01.2016 um 11:01 schrieb Kornel Benko <[email protected]>:
>
> Am Mittwoch, 6. Januar 2016 um 11:39:10, schrieb Jean-Marc Lasgouttes
> <[email protected]>
>> 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<CMakeLists.txt.patch>
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<std::__1::allocator<const lyx::Toc>,
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::__wrap_iter<char const*>,
std::__1::allocator<boost::sub_match<std::__1::__wrap_iter<char const*> > >,
boost::regex_traits<char, boost::cpp_regex_traits<char> > >::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::__wrap_iter<char const*>,
std::__1::allocator<boost::sub_match<std::__1::__wrap_iter<char const*> > >,
boost::regex_traits<char, boost::cpp_regex_traits<char> > >::extend_stack() in
ExternalTransforms.o
boost::re_detail::perl_matcher<std::__1::__wrap_iter<char const*>,
std::__1::allocator<boost::sub_match<std::__1::__wrap_iter<char const*> > >,
boost::regex_traits<char, boost::cpp_regex_traits<char> > >::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 <boost/any.hpp>
^
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 caused by the detection of libiconv and libz at the location
/opt/local/lib/libiconv.dylib and /opt/local/lib/libz.dylib.
I don’t know, how to avoid that because /opt/local/bin/cmake is using
these libraries (at least libz.dylib) internally too.
$ otool -L /opt/local/bin/cmake
/opt/local/bin/cmake:
/opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current
version 8.0.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.8)
/opt/local/lib/libarchive.13.dylib (compatibility version 15.0.0,
current version 15.2.0)
/opt/local/lib/libcurl.4.dylib (compatibility version 9.0.0, current
version 9.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1256.14.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1226.10.1)
ATM, I’m stuck. The auto tools build system is working on Mac OS X 10.11 -
cmake not.
Stephan
PS: With my Mac OS X 10.8 system it works.
- cmake 3.3.1
- clang 5.1 based on LLVM 3.4
