On Tue, Mar 20, 2012 at 12:34 AM, Kapps wrote:
> On Monday, 19 March 2012 at 10:57:13 UTC, Manu wrote:
>>
>> On 19 March 2012 10:59, Manu wrote:
>>
>>> On 17 March 2012 21:37, Andrej Mitrovic
>>> wrote:
>>>
On 3/17/12, Manu wrote:
> Did find that one, but now missing libppl_c-4.dll
>>>
On Monday, 19 March 2012 at 10:57:13 UTC, Manu wrote:
On 19 March 2012 10:59, Manu wrote:
On 17 March 2012 21:37, Andrej Mitrovic
wrote:
On 3/17/12, Manu wrote:
> Did find that one, but now missing libppl_c-4.dll
> This is a bit silly. A binary toolchain needs to have these
> in the
arch
On 3/18/2012 12:32 PM, Johannes Pfau wrote:
I thought about supporting emulated tls a little. The GCC emutls.c
implementation currently can't work with the gc, as every TLS variable
is allocated individually and therefore we don't have a contiguous
memory region for the gc. I think these are the
On 2012-03-19 16:57, Johannes Pfau wrote:
Am Mon, 19 Mar 2012 10:40:25 +0100
schrieb Jacob Carlborg:
In general I was hoping that the work done by the dynamic loader to
setup TLS could be moved to druntime.
That'd be nice, but I think the runtime linker doesn't export all
necessary informat
On 19 March 2012 15:25, Johannes Pfau wrote:
> Am Mon, 19 Mar 2012 09:22:01 +
> schrieb Iain Buclaw :
>
>> On 19 March 2012 08:15, Johannes Pfau wrote:
>> >
>> > * Our own, emulated TLS support is implemented in GCC. This means
>> > it's also used in C, which is great. Also GCC's emulated tls
Am Mon, 19 Mar 2012 10:40:25 +0100
schrieb Jacob Carlborg :
> On 2012-03-19 09:15, Johannes Pfau wrote:
> > Am Sun, 18 Mar 2012 21:57:57 +0100
> > schrieb Jacob Carlborg:
> >
> >> On 2012-03-18 12:32, Johannes Pfau wrote:
> >>> I thought about supporting emulated tls a little. The GCC emutls.c
> >
Am Mon, 19 Mar 2012 09:22:01 +
schrieb Iain Buclaw :
> On 19 March 2012 08:15, Johannes Pfau wrote:
> >
> > * Our own, emulated TLS support is implemented in GCC. This means
> > it's also used in C, which is great. Also GCC's emulated tls needs
> > absolutely no special features in the runti
On 19 March 2012 10:59, Manu wrote:
> On 17 March 2012 21:37, Andrej Mitrovic wrote:
>
>> On 3/17/12, Manu wrote:
>> > Did find that one, but now missing libppl_c-4.dll
>> > This is a bit silly. A binary toolchain needs to have these in the
>> archive.
>> > No point if you can't run it.
>>
>> I
On 2012-03-19 09:17, Johannes Pfau wrote:
Am Sun, 18 Mar 2012 22:06:41 +0100
schrieb Jacob Carlborg:
Yes, but OSX still uses emulated tls. With the way dmd emulates TLS
it's possible to remove __tls_beg and __tls_end, but for native TLS
those symbols are still needed. However, as the runtime l
On 2012-03-19 09:15, Johannes Pfau wrote:
Am Sun, 18 Mar 2012 21:57:57 +0100
schrieb Jacob Carlborg:
On 2012-03-18 12:32, Johannes Pfau wrote:
I thought about supporting emulated tls a little. The GCC emutls.c
implementation currently can't work with the gc, as every TLS
variable is allocated
On 19 March 2012 08:15, Johannes Pfau wrote:
> Am Sun, 18 Mar 2012 21:57:57 +0100
> schrieb Jacob Carlborg :
>
>> On 2012-03-18 12:32, Johannes Pfau wrote:
>> > I thought about supporting emulated tls a little. The GCC emutls.c
>> > implementation currently can't work with the gc, as every TLS
>>
On 17 March 2012 21:37, Andrej Mitrovic wrote:
> On 3/17/12, Manu wrote:
> > Did find that one, but now missing libppl_c-4.dll
> > This is a bit silly. A binary toolchain needs to have these in the
> archive.
> > No point if you can't run it.
>
> I think I've had the same issues before because I
Am Sun, 18 Mar 2012 22:06:41 +0100
schrieb Jacob Carlborg :
> On 2012-03-18 19:39, Johannes Pfau wrote:
>
> > You mean getting rid of __tls_beg and __tls_end? I'd also like to
> > remove those, but:
>
> __tls_beg and __tls_end is not used by Mac OS X any more:
>
> https://github.com/D-Programmi
Am Sun, 18 Mar 2012 21:57:57 +0100
schrieb Jacob Carlborg :
> On 2012-03-18 12:32, Johannes Pfau wrote:
> > I thought about supporting emulated tls a little. The GCC emutls.c
> > implementation currently can't work with the gc, as every TLS
> > variable is allocated individually and therefore we d
14 matches
Mail list logo