[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