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

MacPorts noreply at macports.org
Sun Jun 29 22:42:36 PDT 2014


#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 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?  I wrote that
 macro in order to "deal with" different notations for TLS markup.  It
 doesn't actually cause an abort if it can't find anything.  It just leaves
 TLS undefined.  Your code may not be using it properly.  You may have a
 single global instead!  Perhaps that's a flaw in the macro, but it's up to
 the implementer to check the macro like:

 {{{
 #ifdef TLS
   int TLS myInt;
 #else
   // Visit pthread_key_* hell
 #endif
 }}}

 As for gcc... maybe they just never closed the bug... ?

 {{{
 ~ $ cat test_thread.c
 #include <pthread.h>
 #include <stdio.h>

 #define NUM_THREADS 5

 int __thread value;

 void * test_thread(void *arg) {
     return &value;
 }

 int main(void) {
     int i;
     pthread_t thread[NUM_THREADS];

     for(i=0; i < 5; i++) {
         pthread_create(&thread[i], NULL, test_thread, NULL);
     }

     for(i=0; i < 5; i++) {
         void *loc;
         pthread_join(thread[i], &loc);
         printf("%p\n", loc);
     }

     return 0;
 }

 $ gcc-mp-4.6 test_thread.c

 $ ./a.out
 0x7fc7b3d00118
 0x7fc7b3e00118
 0x7fc7b3f00118
 0x7fc7b3d00118
 0x7fc7b3c03b28
 }}}

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


More information about the macports-tickets mailing list