On Wed, 13 Apr 2016 17:51:14 GMT, punkUser wrote:
After running into lots of problems with memory and the GC on x86, I need to move to x64 (which I'd love to just use for everything always) for one of my applications which runs on Windows. Unfortunately I've been unable to make this work even with a trivial dub/empty vibe application.
As the vibe page notes, libevent DLLs are missing for x64. I could compile those myself but I'd actually rather switch to try out win32 or libasync. Unfortunately even setting those via "subConfigurations" as described in the Vibe readme it still fails to build. From the DUB output from a 32-bit build, it looks like it always builds vibed:core using "libevent", while the final "vibed" will get built using whatever subconfiguration is selected. I haven't tested what happens at runtime, but this seems wrong from the start. Given that I'm using a trivial example, I'm curious what's going wrong.
As per my previous posts, I'll readily admit to being confused about how all the dub configurations and packages stuff ties together, but I'm just following instructions here and yet it doesn't seem to be working.
I think you are hitting a bug in DUB that was recently fixed. Can you try with the latest alpha version or GIT master?
Assuming I get this working, is there some way in the DUB file to specify a 64-bit build rather than having it on the command line every time? Similarly, is there some way in generating a VisualD project that builds the 64-bit version rather than 32-bit?
DUB currently always defaults to the platform that the compiler defaults to. Maybe there is a way to do this in dmd.conf? But it would probably also make sense to add a configuration option to DUB's configuration file. As a workaround, you could create a little batch file that just runs dub --arch=x86_64 %* and use that instead of the dub executable directly.
You can generate a 64-bit VisualD solution using dub generate visuald --arch=x86_64.
I'd love to move entirely away from 32-bit at this point and I have in most other languages. D tends to hang on a bit stubbornly to 32-bit (on Windows) though which is unfortunately considering it has the additional GC issues there.
Yeah, it's really time to have a linker in the standard distribution that can link 64-bit object files. That's the only thing holding back a 64-bit default build.