[MacPorts] #44062: root6: make it work on 10.6

[MacPorts]

#44062: root6: make it work on 10.6
----------------------+-------------------------
  Reporter:  mojca@…  |      Owner:  mojca@…
      Type:  defect   |     Status:  closed
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:
Resolution:  fixed    |   Keywords:  snowleopard
      Port:  root6    |
----------------------+-------------------------

Comment (by egall@…):

 Replying to [comment:60 jeremyhu@…]:
 > Replying to [comment:59 egall@…]:
 > > > Yes.  Checking for the existence of the MAC_OS_X_VERSION_10_7 macro
 is certainly not the right thing to do.  Shame on them.  The compiler and
 deployment target determine if TLS is supported, not the existence of some
 macro.
 > > >
 > >
 > > So now I am getting kind of confused as to how exactly TLS support
 works... You say compiler '''and''' deployment target both matter, but how
 exactly do they interact?
 >
 > Yes.  The compiler needs to know about the `__thread` keyword and what
 the author of the code means by that keyword.  In order for the compiler
 to emit code, the runtime being targeted needs to have some mechanism to
 implement thread local storage.
 >
 > > Is one of the two more important?
 >
 > No.  If the compiler doesn't understand `__thread`, it doesn't matter if
 the runtime supports it or not.  Similarly, if the runtime doesn't have
 TLS support, there's no way that the compiler can translate `__thread`
 into something meaningful.
 >
 > > The other tickets I found (#36172, #38493) all seemed to be unsure as
 to whether it was the compiler or deployment target that was more
 important, as well...
 >
 > Well, both matter.
 >
 > > This is getting kind of off-topic, but I was actually working on
 porting another package that uses TLS (libbabeltrace, for use with the
 recent update to gdb), and I found that versions of clang that were
 supposed to have TLS support (clang-3.3 here) failed to compile code
 containing `__thread`, so I am assuming that the deployment target must
 have been what made it fail there, but on the other hand, gcc apparently
 does '''not''' actually have TLS support on darwin yet
 ([https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268] is still open), and
 yet I was still able to compile code containing `__thread` with the gcc48
 port (it passed the autoconf conftest from `xorg-tls.m4`, too), so I am
 assuming that gcc48 must have just ignored the deployment target or
 something?
 >
 > What do you mean "passed the autoconf test from xorg-tls.m4"?

 It returned "`__thread`" properly. Also I see you commented on the
 upstream gcc ticket as well, and it turns out that it was the emutls vs.
 native TLS thing that was confusing me. However, this raises some
 additional questions. If gcc is able to use emutls as a way of supporting
 TLS on systems where it is unsupported natively (i.e. 10.6 and earlier),
 is there a way to get clang to do similarly? So far I have not found one
 yet... Also, I came up with the following blacklist for projects that only
 need to blacklist based on TLS support:
 {{{
 if {${os.platform} eq "darwin"} {
     # uses thread-local storage, which gcc only supports via emutls
     # on darwin as of gcc45 and later:
     compiler.blacklist-append gcc-3.3 {*gcc-4.[0-4]}
     if {${os.major} >= 11} {
         # old versions of clang (from before Xcode 4.2.1) need to be
         # blacklisted for not supporting thread-local storage as well:
         compiler.blacklist-append {clang < 318.0.61}
         # blacklist the equivalent clangs from MacPorts, too:
         compiler.blacklist-append macports-clang-2.9 macports-clang-3.0
     } else {
         # clang does not support TLS at all on pre-Lion systems, not even
         # via emutls like gcc does, so blacklist all clangs:
         compiler.blacklist-append *clang*
         # Make sure a recent version of gcc supporting emutls is in the
         # fallback list:
         compiler.fallback-append macports-gcc-4.8
     }
 } else {
     # not sure what to blacklist on other platforms...
 }
 }}}
 Would that be an accurate blacklist, more-or-less?

 (but anyways, this is getting kind of off-topic from root6... sorry for
 the derail...)

-- 
Ticket URL: <https://trac.macports.org/ticket/44062#comment:61>
MacPorts <http://www.macports.org/>
Ports system for OS X