We currently require OS X 10.4. This is now a very old version of OS X and supporting it makes things difficult for us as a lot of APIs and features tend to change with each major version. Market share wise, 10.6 is the oldest version in any significant use these days. Most users are running the latest version (10.9): http://appleinsider.com/articles/14/03/27/adoption-of-os-x-109-mavericks-significantly-outpaces-108-mountain-lion It is also worth noting that 10.6 and newer is free to upgrade to 10.9. We might also consider switching to 64-bit, for future proofing and performance increases. Google decided to go 64-bit only with the latest version of Chrome: http://blog.chromium.org/2014/08/mac-chrome-when-im-sixty-four-bits.html
The plan is to raise the requirements to OS X 10.6, and provide only a 64 bit version. I've installed a Mac with 10.6 in our lab. Did a new installation of OS X Server, since this is what we have. As I understand it, the fact that this is a "Server" edition should not matter. After all upgrades, the OS X version is 10.6.8. Note that this machine is not capable of running a 64-bit kernel. However, OS X supports running 64 bit applications on 32 bit kernels. I've verified that this is the case by running Chrome 39, which is 64-bit.
"Xcode 4.2 for Snow Leopard" has now been installed on our 10.6 machine. Apparently this is the latest version that still runs on 10.6.
Wrt odcctools: * Last time we fetched from http://iphone-dev.googlecode.com/svn/branches/odcctools-9.2-ld, but there's no new version there. Last updated 2009-08-17. Based on cctools 622. * http://wiki.lazarus.freepascal.org/Cross_compiling_OSX_on_Linux links to http://svn.macosforge.org/repository/odcctools/trunk/. Last updated 2010-04-19. Now based on cctools 758. http://www.nathancoulson.com/proj_cross.php also refers to this version. cctools is available from http://www.opensource.apple.com/source/cctools/.
There's a sligtly updated version at https://github.com/javacom/toolchain4/tree/master/cctools2odcctools. According to the changelog, it is based on cctools-782 rather than cctools-758. This is 2 public releases newer, and in total 24 versions newer. Should probably try this version instead.
Should check out https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229. GCC 4.6 seems like a good version, at a glance.
After odcctools upgrade, FLTK no longer builds, neither in the osx32 or the new osx64 environment. Downgrading to odcctools 758 does not help. Error: ld: in CMakeFiles/fltk_SHARED.dir/Fl_cocoa.mm.o, S_LITERAL_POINTERS section __OBJC,__message_refs missing relocs I found https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708 which mentions this as a 4.8 regression, also affecting 4.7. A backported patch for 4.7 is available. It also applies to 4.6.4, but does not solve the problem. Perhaps not a surprise, since the claim that the problem was introduced by revisions 188235/188243, but these commits were on trunk, as far as I can tell.
In r30030, we tweaked GCC to have __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ = 1060 by default. However, apparently a lot of logic checks if you are specifying -mmacosx-version-min, so if you do, you'll get a different behaviour: $ cbrun osx64 `cbparam osx64 host`-gcc -Wall foo.c -mmacosx-version-min=10.6 ld: unknown option: -no_compact_unwind collect2: ld returned 1 exit status This is the infamous problem mentioned at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229: "You will need to fake a darwin10 "ld" that can handle the "-no_compact_unwind" unwind flag (or comment that section out of config/darwin10.h)." So, first of all, we need to either: 1) Patch all GCC logic so that it assumes 10.6 even though -mmacosx-version-min=10.6 is not specified. or 2) Always specify -mmacosx-version-min=10.6 when building. Then, we need to handle the "-no_compact_unwind" flag. We could: 1) Patch GCC to remove it. Seems to be here: /* Fix PR41260 by passing -no_compact_unwind on darwin10 and later until unwinder in libSystem is fixed to digest new epilog unwinding notes. Fix PR47558 by linking against libSystem ahead of libgcc_ext. */ #undef LINK_GCC_C_SEQUENCE_SPEC #define LINK_GCC_C_SEQUENCE_SPEC \ "%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \ %{!static:%{!static-libgcc: \ %:version-compare(>= 10.6 mmacosx-version-min= -lSystem) } } %G %L" 2) "fake a darwin10 ld that can handle the -no_compact_unwind unwind flag". 3) Try to upgrade odcctools to a version which includes a ld that understands -no_compact_unwind. We are currently using cctools-782 and ld64-85.2.1; ld64 is what's relevant. The next "major" version is ld64-95.2.12, and it actually supports this flag.
*** Bug 5450 has been marked as a duplicate of this bug. ***
GCC has been patched (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65294). Our odcctools now ignores the -no_compact_unwind argument. With r30079, we are building the OS X client in the osx64 environment and documenting the new requirements. Closing.
I've done several tests on Mac OS X 10.10 today, of an osx64 build of the client. It seems to work fine. Tested: * Local drive redirection, read and write * Printing to local printer, using the new print dialog. * Smart card redirection and authentication. * Multiple monitor support * Fullscreen * Video playback Seems to work fine - additional tests can be performed during the release testing.
Something is off. I've seen crashes at least twice now on the 10.6 device. All of them had a call to abort(), but otherwise different call stacks. I haven't yet seen a way to reproduce crashes though. The most recent stack trace: Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff815d50b6 __kill + 10 1 libSystem.B.dylib 0x00007fff816759f6 abort + 83 2 se.cendio.tlclient 0x0000000100123366 operator new(unsigned long) + 9174 3 se.cendio.tlclient 0x0000000100123a87 operator new(unsigned long) + 10999 4 se.cendio.tlclient 0x0000000100119391 operator delete(void*) + 8769 5 se.cendio.tlclient 0x000000010002d26e XmlRpc::XmlRpcValue::operator[](char const*) + 19626 6 se.cendio.tlclient 0x000000010002d7cf XmlRpc::XmlRpcValue::operator[](char const*) + 21003 7 se.cendio.tlclient 0x000000010002de23 XmlRpc::XmlRpcValue::operator[](char const*) + 22623 8 se.cendio.tlclient 0x000000010002ee27 XmlRpc::XmlRpcValue::operator[](char const*) + 26723 9 se.cendio.tlclient 0x00000001000279b9 SmartcardAdvancedWindow::browser_item_data::~browser_item_data() + 49437 10 se.cendio.tlclient 0x000000010000ec9e std::_Rb_tree<std::string, std::pair<std::string const, std::vector<std::string, std::allocator<std::string> > >, std::_Select1st<std::pair<std::string const, std::vector<std::string, std::allocator<std::string> > > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::vector<std::string, std::allocator<std::string> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::string const, std::vector<std::string, std::allocator<std::string> > > >*) + 38446 11 se.cendio.tlclient 0x000000010000fe05 std::_Rb_tree<std::string, std::pair<std::string const, std::vector<std::string, std::allocator<std::string> > >, std::_Select1st<std::pair<std::string const, std::vector<std::string, std::allocator<std::string> > > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::vector<std::string, std::allocator<std::string> > > > >::_M_erase(std::_Rb_tree_node<std::pair<std::string const, std::vector<std::string, std::allocator<std::string> > > >*) + 42901 12 se.cendio.tlclient 0x0000000100080530 Fl_Valuator::~Fl_Valuator() + 2672 13 se.cendio.tlclient 0x000000010006f4ee Fl_Repeat_Button::~Fl_Repeat_Button() + 814
At the moment I can reproduce this by entering an invalid server name. The client crashes after closing the subsequent error dialog. Running tlclient on the command line does not give any more clues. Only the text "Abort trap" is printed.
A debug build gave me this different stack trace, with the same test case: Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff815d50b6 __kill + 10 1 libSystem.B.dylib 0x00007fff816759f6 abort + 83 2 se.cendio.tlclient 0x0000000100123296 uw_init_context_1 + 198 3 se.cendio.tlclient 0x00000001001239b7 _Unwind_RaiseException + 55 4 se.cendio.tlclient 0x00000001001192c1 __cxa_throw + 81 5 se.cendio.tlclient 0x000000010002d0ee SSHTunnel::ProcessLine(std::string const&) + 5244 6 se.cendio.tlclient 0x000000010002d64f SSHTunnel::ProcessBuffer(char const*, std::string*) + 141 7 se.cendio.tlclient 0x000000010002dca3 SSHTunnel::Connect(ArgVector, char const*) + 1529 8 se.cendio.tlclient 0x000000010002eca7 SSHTunnel::EstablishTunnel() + 3639 9 se.cendio.tlclient 0x0000000100027839 Session::ConnectMaster() + 509 10 se.cendio.tlclient 0x000000010000eb1e MainWindow::DoLogin(std::string, std::string, std::string, std::string, pkcs11_certificate const*, std::string const&, std::string, bool) + 1386 11 se.cendio.tlclient 0x000000010000fc85 MainWindow::TriggerLogin() + 1599 12 se.cendio.tlclient 0x0000000100080460 Fl_Widget::do_callback(Fl_Widget*, void*) + 48 13 se.cendio.tlclient 0x000000010006f41e Fl_Return_Button::handle(int) + 78
Possibly relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Comments suggest this may have been fixed somewhere between 4.5 and 4.8. Noone has properly re-tested on 10.6 though.
The simple test case in that gcc bug report provokes the issue. But only if we statically link stdc++/gcc_s though. So it would seem like exception handling is completely broken for us on at least OS X.
Problem also happens on 10.10. And it also only affects 64-bit binaries. 32-bit binaries built with the updated gcc and odcctools seem to work fine.
The problem is that gcc's stack unwinding routines are getting upset by something. Not sure if that something is coming from ld64, system libraries or being created in runtime. Using the system's unwinder makes the problem go away so we'll try to get rid of the one in gcc. We've updated the upstream bug report in a hope to get them to reopen it.
Fixed our gcc in r30201.
Works well on 10.6 now. Need to test 10.10 as well.
odcctools has missing requirements: ./extract.sh: line 173: autoheader: command not found error: Bad exit status from /var/tmp/rpm-tmp.f7pN4u (%prep)
Flex refuses to build translations for osx64 for some reason: error: File not found by glob: /home/tltest/cenbuild/repo/rpmbuild/BUILDROOT/cendio-build-flex-osx64-2.5.35-4.i386/opt/cendio-build/arch/osx64/usr/x86_64-apple-darwin10/sys-root/usr/share/locale/*/LC_MESSAGES/flex.mo
(In reply to comment #20) > odcctools has missing requirements: > > ./extract.sh: line 173: autoheader: command not found > error: Bad exit status from /var/tmp/rpm-tmp.f7pN4u (%prep) r30238. (In reply to comment #21) > Flex refuses to build translations for osx64 for some reason: > > error: File not found by glob: > /home/tltest/cenbuild/repo/rpmbuild/BUILDROOT/cendio-build-flex-osx64-2.5.35-4.i386/opt/cendio-build/arch/osx64/usr/x86_64-apple-darwin10/sys-root/usr/share/locale/*/LC_MESSAGES/flex.mo It needs libintl to enable translations. r30239.
Tested 10.10. Could not find any issues.
