On 09/25/2013 02:30 AM, Michael Meeks wrote:
* release builds (Norbert)
+ propose continue doing 10.6 for 32bit, and 10.8 for 64bit
+ more and more SDK pieces are harder and harder to get to
work on old releases
AI: + switch to 10.8 baseline for 64bit (Norbert)
+ ultimately, gerrit will do both with DavidO's help
One consequence of a Mac OS X 10.8 based build that comes to mind is
that Clang does not support GCC's -fno-enforce-eh-specs. So since a
10.8 based build would necessarily(?) use a true Clang, we would be back
with a platform where even --disable-dbgutil builds could run into
std::unexpected aborts. (Those exception violations appear to be rare
in practice, and are bugs that need to be fixed anyway, so this should
not be too big an issue; just want to mention it.)
(According to e.g.
<http://dev-builds.libreoffice.org/daily/libreoffice-4-1/MacOSX-Intel@27-OSX_10.7.0-gcc_4.2.1_llvm/2013-10-14_10.42.26/libreoffice-4-1~2013-10-14_10.42.26_build_info.txt>
checking whether /usr/local/bin/ccache g++-4.2 -m32 -mmacosx-version-min=10.6 -isysroot
/Developer/SDKs/MacOSX10.6.sdk supports -fno-enforce-eh-specs... yes
the 10.6 based builds apparently use an (Apple-variant) GCC that still
supports -fno-enforce-eh-specs.)
Stephan
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.