www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Anyone using DMD to build 32bit on OS X?

reply Jacob Carlborg <doob me.com> writes:
I've implemented native TLS in DMD on OS X for 64bit. Now the question 
is, does it need to work for 32bit as well?

The easiest would be to drop the 32bit support all together. Other 
options would be to continue to use emulate TLS on 32bit or implement 
native TLS for 32bit as well. I would prefer to not have to do this for 
32bit as well.

As far as I know we haven't released a 32bit binary of DMD for a very 
long time. It would be very rare to find a Mac that cannot run 64bit 
binaries.

Native TLS on OS X would mean that the runtime requirements for the 
binaries produced by DMD on OS X would be OS X 10.7 (Lion) or later. 
Hopefully that should not be a problem since it's several years (and 
versions) old.

-- 
/Jacob Carlborg
Jan 10
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Sunday, 10 January 2016 at 17:12:40 UTC, Jacob Carlborg wrote:
 The easiest would be to drop the 32bit support all together. 
 Other options would be to continue to use emulate TLS on 32bit 
 or implement native TLS for 32bit as well. I would prefer to 
 not have to do this for 32bit as well.
I would suggest dropping 32bit OSX support, especially since it doesn't exist anymore. Mountain Lion, which was released in 2012, was the last version to ship a 32bit version. And you're right, DMD doesn't even have a 32bit binary for download. Also, the probability of extra bugs in the 32bit OSX is high, due to the fact that no one uses it.
Jan 10
parent Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 10 January 2016 at 18:06:11 UTC, Jack Stouffer wrote:
 Mountain Lion, which was released in 2012, was the last version 
 to ship a 32bit version.
But 32-bit programs still work on latest OSX, and are sometimes needed.
Jan 10
prev sibling next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Sunday, 10 January 2016 at 17:12:40 UTC, Jacob Carlborg wrote:
 I've implemented native TLS in DMD on OS X for 64bit. Now the 
 question is, does it need to work for 32bit as well?

 The easiest would be to drop the 32bit support all together. 
 Other options would be to continue to use emulate TLS on 32bit 
 or implement native TLS for 32bit as well. I would prefer to 
 not have to do this for 32bit as well.

 As far as I know we haven't released a 32bit binary of DMD for 
 a very long time. It would be very rare to find a Mac that 
 cannot run 64bit binaries.

 Native TLS on OS X would mean that the runtime requirements for 
 the binaries produced by DMD on OS X would be OS X 10.7 (Lion) 
 or later. Hopefully that should not be a problem since it's 
 several years (and versions) old.
I definitely don't care about 32 bit on OS X. However, I see no need to drop it if the current TLS emulation works.
Jan 10
parent Jacob Carlborg <doob me.com> writes:
On 2016-01-10 20:42, John Colvin wrote:

 I definitely don't care about 32 bit on OS X. However, I see no need to
 drop it if the current TLS emulation works.
It's easier to remove it than supporting both :) -- /Jacob Carlborg
Jan 10
prev sibling next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Sunday, 10 January 2016 at 17:12:40 UTC, Jacob Carlborg wrote:
 I've implemented native TLS in DMD on OS X for 64bit. Now the 
 question is, does it need to work for 32bit as well?

 The easiest would be to drop the 32bit support all together. 
 Other options would be to continue to use emulate TLS on 32bit 
 or implement native TLS for 32bit as well. I would prefer to 
 not have to do this for 32bit as well.

 As far as I know we haven't released a 32bit binary of DMD for 
 a very long time. It would be very rare to find a Mac that 
 cannot run 64bit binaries.

 Native TLS on OS X would mean that the runtime requirements for 
 the binaries produced by DMD on OS X would be OS X 10.7 (Lion) 
 or later. Hopefully that should not be a problem since it's 
 several years (and versions) old.
Awesome! Is there a way I can have a look at the code? I'd like to start looking into how this will fit together with shared library support. Thanks, Bit
Jan 10
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-10 21:58, bitwise wrote:

 Awesome!

 Is there a way I can have a look at the code? I'd like to start looking
 into how this will fit together with shared library support.
https://github.com/D-Programming-Language/dmd/pull/5346 -- /Jacob Carlborg
Jan 10
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Monday, 11 January 2016 at 07:40:37 UTC, Jacob Carlborg wrote:
 On 2016-01-10 21:58, bitwise wrote:

 Awesome!

 Is there a way I can have a look at the code? I'd like to 
 start looking
 into how this will fit together with shared library support.
https://github.com/D-Programming-Language/dmd/pull/5346
So..I've only had time to glance at the code, but it looks like you've effectively moved this issue out of the way of shared libraries entirely, and that no interaction between shared libs and TLS is needed at all..is this correct? Bit
Jan 11
parent Jacob Carlborg <doob me.com> writes:
On 2016-01-11 23:44, bitwise wrote:

 So..I've only had time to glance at the code, but it looks like you've
 effectively moved this issue out of the way of shared libraries
 entirely, and that no interaction between shared libs and TLS is needed
 at all..is this correct?
Yes, I think so. I haven't implemented dynamic libraries so I can't be entirely sure :) Now it shouldn't require any more code or complications than for Linux. You still, at least, need to make sure that _d_dyld_getTLSRange [1] is called for each dynamic library (and the executable). Not sure what we'll do about 32bit. The easiest would probably be to revert back to emulate TLS for 32bit. Unless someone with some better knowledge of DMD could fix the native TLS for 32bit as well :) [1] https://github.com/D-Programming-Language/druntime/pull/1461/files#diff-6e800db47f2f2ea1953538f709516382R36 -- /Jacob Carlborg
Jan 12
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 10 January 2016 at 17:12:40 UTC, Jacob Carlborg wrote:
 I've implemented native TLS in DMD on OS X for 64bit. Now the 
 question is, does it need to work for 32bit as well?

 The easiest would be to drop the 32bit support all together. 
 Other options would be to continue to use emulate TLS on 32bit 
 or implement native TLS for 32bit as well. I would prefer to 
 not have to do this for 32bit as well.

 As far as I know we haven't released a 32bit binary of DMD for 
 a very long time. It would be very rare to find a Mac that 
 cannot run 64bit binaries.

 Native TLS on OS X would mean that the runtime requirements for 
 the binaries produced by DMD on OS X would be OS X 10.7 (Lion) 
 or later. Hopefully that should not be a problem since it's 
 several years (and versions) old.
I'm using 32-bit support of DMD and I would strongly prefer if it wasn't removed. At least staying the same as today. The problem is that I don't control what bitness users want, because of network effects some users still use 32-bit software. Every product in this space is Universal Binaries with both 32-bit and 64-bit arch. You can drop OSX 10.6, which is not officially supported anyway, it would bring compat the same as LDC. No problem as far as I'm concerned, very few people are using 10.6 (at least that's what they say in polls). I have a question, does your work solves shared libraries leaking after unload, or is it unrelated? :)
Jan 10
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-10 23:15, Guillaume Piolat wrote:

 I'm using 32-bit support of DMD and I would strongly prefer if it wasn't
 removed. At least staying the same as today.

 The problem is that I don't control what bitness users want, because of
 network effects some users still use 32-bit software. Every product in
 this space is Universal Binaries with both 32-bit and 64-bit arch.
Fair enough.
 You can drop OSX 10.6, which is not officially supported anyway, it
 would bring compat the same as LDC. No problem as far as I'm concerned,
 very few people are using 10.6 (at least that's what they say in polls).
Ok, that would mean 10.7 for 64bit and 10.6 (or whatever the current requirements are) for 32bit.
 I have a question, does your work solves shared libraries leaking after
 unload, or is it unrelated? :)
I doesn't solve the problem but it's a prerequisite for solving dynamic libraries. That's why I started working on this :) -- /Jacob Carlborg
Jan 10
parent ponce <contact gam3sfrommars.fr> writes:
On Monday, 11 January 2016 at 07:44:18 UTC, Jacob Carlborg wrote:
 I doesn't solve the problem but it's a prerequisite for solving 
 dynamic libraries. That's why I started working on this :)
Great!
Jan 11
prev sibling next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Sunday, 10 January 2016 at 17:12:40 UTC, Jacob Carlborg wrote:
 I've implemented native TLS in DMD on OS X for 64bit. Now the 
 question is, does it need to work for 32bit as well?

 The easiest would be to drop the 32bit support all together. 
 Other options would be to continue to use emulate TLS on 32bit 
 or implement native TLS for 32bit as well. I would prefer to 
 not have to do this for 32bit as well.

 As far as I know we haven't released a 32bit binary of DMD for 
 a very long time. It would be very rare to find a Mac that 
 cannot run 64bit binaries.

 Native TLS on OS X would mean that the runtime requirements for 
 the binaries produced by DMD on OS X would be OS X 10.7 (Lion) 
 or later. Hopefully that should not be a problem since it's 
 several years (and versions) old.
Thanks! Only 64 bits
Jan 11
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/10/2016 9:12 AM, Jacob Carlborg wrote:
 I've implemented native TLS in DMD on OS X for 64bit. Now the question is, does
 it need to work for 32bit as well?

 The easiest would be to drop the 32bit support all together. Other options
would
 be to continue to use emulate TLS on 32bit or implement native TLS for 32bit as
 well. I would prefer to not have to do this for 32bit as well.

 As far as I know we haven't released a 32bit binary of DMD for a very long
time.
 It would be very rare to find a Mac that cannot run 64bit binaries.

 Native TLS on OS X would mean that the runtime requirements for the binaries
 produced by DMD on OS X would be OS X 10.7 (Lion) or later. Hopefully that
 should not be a problem since it's several years (and versions) old.
From reading the responses here, I believe the best solution is to continue to support OSX 32 bit, but as legacy support. This means folding in changes to the 64 bit support, but not adding features if they are not a natural consequence of the 64 bit support. I.e. leave the TLS support for 32 bits as is. If somebody wants to take on the task of native 32 bit TLS, I welcome that, but it's not something we need to do. There's no need for a 32 bit binary of dmd, as 32 bit only OSX machines are long gone.
Jan 12
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-12 17:48, Walter Bright wrote:

  From reading the responses here, I believe the best solution is to
 continue to support OSX 32 bit, but as legacy support. This means
 folding in changes to the 64 bit support, but not adding features if
 they are not a natural consequence of the 64 bit support.

 I.e. leave the TLS support for 32 bits as is.
I came to the same conclusions. I'll update the PR. -- /Jacob Carlborg
Jan 12
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/12/2016 03:30 PM, Jacob Carlborg wrote:
 On 2016-01-12 17:48, Walter Bright wrote:

  From reading the responses here, I believe the best solution is to
 continue to support OSX 32 bit, but as legacy support. This means
 folding in changes to the 64 bit support, but not adding features if
 they are not a natural consequence of the 64 bit support.

 I.e. leave the TLS support for 32 bits as is.
I came to the same conclusions. I'll update the PR.
Thanks much for this work! -- Andrei
Jan 12
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/12/2016 12:36 PM, Andrei Alexandrescu wrote:
 On 01/12/2016 03:30 PM, Jacob Carlborg wrote:
 On 2016-01-12 17:48, Walter Bright wrote:

  From reading the responses here, I believe the best solution is to
 continue to support OSX 32 bit, but as legacy support. This means
 folding in changes to the 64 bit support, but not adding features if
 they are not a natural consequence of the 64 bit support.

 I.e. leave the TLS support for 32 bits as is.
I came to the same conclusions. I'll update the PR.
Thanks much for this work! -- Andrei
I agree! Going to native TLS is the right way forward for 64 bits.
Jan 12
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Tuesday, 12 January 2016 at 21:28:43 UTC, Walter Bright wrote:
 On 1/12/2016 12:36 PM, Andrei Alexandrescu wrote:
 On 01/12/2016 03:30 PM, Jacob Carlborg wrote:
 On 2016-01-12 17:48, Walter Bright wrote:

  From reading the responses here, I believe the best 
 solution is to
 continue to support OSX 32 bit, but as legacy support. This 
 means
 folding in changes to the 64 bit support, but not adding 
 features if
 they are not a natural consequence of the 64 bit support.

 I.e. leave the TLS support for 32 bits as is.
I came to the same conclusions. I'll update the PR.
Thanks much for this work! -- Andrei
I agree! Going to native TLS is the right way forward for 64 bits.
Would having shared libraries for 64bit only be ok too? I would like to avoid having to update the emulated TLS if possible. Thanks, Bit
Jan 12
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/12/2016 2:20 PM, bitwise wrote:
 On Tuesday, 12 January 2016 at 21:28:43 UTC, Walter Bright wrote:
 On 1/12/2016 12:36 PM, Andrei Alexandrescu wrote:
 On 01/12/2016 03:30 PM, Jacob Carlborg wrote:
 On 2016-01-12 17:48, Walter Bright wrote:

  From reading the responses here, I believe the best solution is to
 continue to support OSX 32 bit, but as legacy support. This means
 folding in changes to the 64 bit support, but not adding features if
 they are not a natural consequence of the 64 bit support.

 I.e. leave the TLS support for 32 bits as is.
I came to the same conclusions. I'll update the PR.
Thanks much for this work! -- Andrei
I agree! Going to native TLS is the right way forward for 64 bits.
Would having shared libraries for 64bit only be ok too?
If they're not already there for 32 bit, then yes.
 I would like to avoid having to update the emulated TLS if possible.

 Thanks,
      Bit
Jan 12