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
<st.w...@gmx.net>
> Am 07.01.2016 um 11:01 schrieb Kornel Benko <kor...@lyx.org>:
> >
> > Am Mittwoch, 6. Januar 2016 um 11:39:10, schrieb Jean-Marc Lasgouttes
> > <lasgout...@lyx.org>
> >> 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
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<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
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 <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.
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/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
Looks good.
Kornel
signature.asc
Description: This is a digitally signed message part.
