Thread overview
Re: DMD, LDC, and GDC compilers and 32/64 bit
Jun 18, 2017
David Nadlinger
Jun 19, 2017
kinke
Jun 19, 2017
Russel Winder
Jun 19, 2017
Jacob Carlborg
Jun 19, 2017
David Nadlinger
June 18, 2017
On 18 Jun 2017, at 17:08, Russel Winder via digitalmars-d-ldc wrote:
> It appears at some time in the past that some of the compilers when
> compiled as 32-bit executables, could not generate 64-bit objects and
> executables as they did not understand the -m64 option, it was not
> compiled in.

Both -m32 and -m64 are available on any host with LDC. However, usually you wouldn't find 64 bit standard libraries with a 32 bit build – not because of any technical reason, but just because multilib setups in that direction are far less useful/common.

> Is there a way to determine the bitsize of the compiler executable, in
> the test it is assumed that if the OS is 32-bit then so are the D
> compilers.

It seems both simpler and more accurate to just test whether "$DMD -m64 -main empty.d" (with an empty source file) succeeds.

 — David
June 19, 2017
On Sun, 2017-06-18 at 18:42 +0100, David Nadlinger via digitalmars-d- ldc wrote:
> 
[…]
> Both -m32 and -m64 are available on any host with LDC. However,
> usually
> you wouldn't find 64 bit standard libraries with a 32 bit build –
> not
> because of any technical reason, but just because multilib setups in
> that direction are far less useful/common.

Hummm… I forgot that aspect. Now I'm feeling a bit stupid. :-)

That though gives me good direction for the ldc tool, thanks.

> > Is there a way to determine the bitsize of the compiler executable,
> > in
> > the test it is assumed that if the OS is 32-bit then so are the D
> > compilers.
> 
> It seems both simpler and more accurate to just test whether "$DMD
> -m64
> -main empty.d" (with an empty source file) succeeds.

That is exactly the test that was there but was commented out due to it failing on the Buildbot CI client network. My problem is knowing whether it should fail or should pass on the platform being used.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

June 19, 2017
On 2017-06-19 10:29, Russel Winder via digitalmars-d-ldc wrote:

> That is exactly the test that was there but was commented out due to it
> failing on the Buildbot CI client network. My problem is knowing
> whether it should fail or should pass on the platform being used.

"uname -m" will tell what the current platform is.

-- 
/Jacob Carlborg
June 19, 2017
On 19 Jun 2017, at 9:29, Russel Winder via digitalmars-d-ldc wrote:
> That is exactly the test that was there but was commented out due to it
> failing on the Buildbot CI client network. My problem is knowing
> whether it should fail or should pass on the platform being used.

This depends entirely on the system configuration. Multilib packages being shipped or not is not something the compiler projects control, but distro packagers/… decide. I don't know the particularities of your CI setup, but I'd probably look to hard-code this along with other host platform configuration options (such as the OS image used, etc.). Testing the correct implementation against dodgy heuristics doesn't seem like a terribly useful thing to do.

 — David
June 19, 2017
On Sunday, 18 June 2017 at 17:42:13 UTC, David Nadlinger wrote:
> Both -m32 and -m64 are available on any host with LDC. However, usually you wouldn't find 64 bit standard libraries with a 32 bit build – not because of any technical reason, but just because multilib setups in that direction are far less useful/common.

Beyond 32/64 bit, does this also affect practical support for other target architectures (e.g. ARM)?

Can you in any case point to some guidelines on how best to build LDC so as to have the maximum possible target support library-wise?  It would be good to try to ensure the snap package supports this.
June 19, 2017
On Monday, 19 June 2017 at 13:36:28 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 18 June 2017 at 17:42:13 UTC, David Nadlinger wrote:
>> Both -m32 and -m64 are available on any host with LDC. However, usually you wouldn't find 64 bit standard libraries with a 32 bit build – not because of any technical reason, but just because multilib setups in that direction are far less useful/common.
>
> Beyond 32/64 bit, does this also affect practical support for other target architectures (e.g. ARM)?
>
> Can you in any case point to some guidelines on how best to build LDC so as to have the maximum possible target support library-wise?  It would be good to try to ensure the snap package supports this.

Well, library-wise all targets we can really support are the 32/64-bit variants of the host. If we shipped our Linux x64 package with ARM libs, it'd still depend on an external cross-linker and the ARM C libs, so bundling LDC with druntime/Phobos for a bunch of other targets doesn't seem to make a lot of sense (to me anyway).

Building static druntime/Phobos libs (generally or even on-demand when first targeting a new platform) for any target supported by the used LLVM would be easily possible on any host with latest LDC - if they didn't include any C parts, which unfortunately complicate matters.