www.cendio.com

Bug 5257

Summary: raise OS X requirements
Product: ThinLinc Reporter: Pierre Ossman <ossman@cendio.se>
Component: Build systemAssignee: Peter Åstrand <astrand@cendio.se>
Status: CLOSED FIXED QA Contact: Bugzilla mail exporter <bugzilla-qa@cendio.se>
Severity: Normal    
Priority: P2 CC: astrand@cendio.se
Version: trunkKeywords: ossman_tester, relnotes
Target Milestone: 4.4.0   
Hardware: PC   
OS: Unknown   
Acceptance Criteria:
Bug Depends on: 5256, 5449    
Bug Blocks: 2182, 5438, 5450, 5456    

Description From cendio 2014-09-15 09:45:00
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
------- Comment #1 From cendio 2015-01-12 15:13:25 -------
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.
------- Comment #2 From cendio 2015-01-19 13:14:43 -------
"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.
------- Comment #3 From cendio 2015-02-12 13:27:01 -------
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/.
------- Comment #4 From cendio 2015-02-13 13:11:06 -------
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.
------- Comment #5 From cendio 2015-02-13 13:20:25 -------
Should check out https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229. GCC 4.6
seems like a good version, at a glance.
------- Comment #6 From cendio 2015-02-19 15:46:53 -------
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.
------- Comment #7 From cendio 2015-02-28 13:33:14 -------
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.
------- Comment #8 From cendio 2015-03-03 09:49:59 -------
*** Bug 5450 has been marked as a duplicate of this bug. ***
------- Comment #9 From cendio 2015-03-03 09:56:50 -------
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.
------- Comment #10 From cendio 2015-03-03 15:53:29 -------
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.
------- Comment #11 From cendio 2015-03-26 12:55:08 -------
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
------- Comment #12 From cendio 2015-03-26 12:59:37 -------
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.
------- Comment #13 From cendio 2015-03-26 13:02:51 -------
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
------- Comment #14 From cendio 2015-03-26 13:13:10 -------
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.
------- Comment #15 From cendio 2015-03-26 13:21:06 -------
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.
------- Comment #16 From cendio 2015-03-26 13:25:26 -------
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.
------- Comment #17 From cendio 2015-03-31 16:23:23 -------
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.
------- Comment #18 From cendio 2015-04-01 13:18:49 -------
Fixed our gcc in r30201.
------- Comment #19 From cendio 2015-04-10 09:53:59 -------
Works well on 10.6 now. Need to test 10.10 as well.
------- Comment #20 From cendio 2015-04-10 13:02:21 -------
odcctools has missing requirements:

./extract.sh: line 173: autoheader: command not found
error: Bad exit status from /var/tmp/rpm-tmp.f7pN4u (%prep)
------- Comment #21 From cendio 2015-04-13 13:39:00 -------
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
------- Comment #22 From cendio 2015-04-15 10:58:58 -------
(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.
------- Comment #23 From cendio 2015-04-15 11:12:19 -------
Tested 10.10. Could not find any issues.