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.