status of 64-bit python / windows support

[captaindet]

i am using windows and 64bit python 3.5 - this is a given for my project. would love to interface with D. tried to get pyd 'hello' example working to no avail (neither with ldc nor dmd), it looks like pyd is 32bit only, at least on windows (finally i discovered: #59 ). if this is the case this should be specified clearly in the readme and on the project home page, so that ppl don't waste hours like i did.

if it should work, then may i ask how to get it working?

as i said, i tried a couple of things including building my own python35_digitalmars.lib to no avail. i'd need a complete walkthrough, something that is sadly missing from the docs.

thx

[ariovistus]

yes it should, sorry about that.

It actually should be doable in theory, but it seems like getting a usable compiler is a deep dark adventure that I have not yet undertaken. I can't recall details off the top of my head. You definitely don't want to be building the digitalmars lib file, because 64 bit dmd doesn't use omf.

[captaindet]

thanks for your reply. however, your comment leaves me more confused than before. let's back up a bit. could you please state clearly (probably best to do so on the project page) what architectures/environments are currently supported (and tested)? is it only 32bit DMD on windows? currently the project page also mentions LDC and what i did was rebuilding the libs w/ LDC/64bit/COFF, but it did not do the trick. it is quite curious though hat the lib names end in '_digitalmars'.

[ariovistus]

:) windows is 32bit dmd only. I've never tried to get any other compiler working on windows.

[captaindet]

this is too bad :(
compilation is not the real problem, or is it? after all, the command line expression for compiling to 64 bit is the same as for 32 bit, just with an added -m64, and it would work for dmd the same as for ldc if using the ldmd2 wrapper. when i add '-m64' to 'extra_compile_args' the first step works alright. but unfortunately the dmd/digitalmars linker is explicitly called in a second step, this is where it falls apart...

[ariovistus]

the only real problem pyd has is configuration wrt the compiler, the linker, the platform, distutils, python, and probably one or two other moving parts that I don't have much control over.

[captaindet]

i got the same impression, that there is no fundamental issue why it should not work. unfortunately, i know nothing about distutils/celerid. i guess what i was trying to say is: if pyd could be made to work w/o explicit call to a linker, i.e. by just calling dmd or ldmd2 (which would then call the linker implicitly according to their opaque configuration), one could pretty much use the same argument list for compilation under windows and linux and dmd and ldmd2 and it would be just a simple adding of '-m64' to go 64 bit.

well, i guess i must be missing something.

[ariovistus]

wait, are you successfully building 64bit windows executables with dmd now?

[captaindet]

yup, this is possible for quite a while now, works like a charm once it is set up properly (but often works out of the box after standard installation procedure). for 64bit.exe dmd does not use the OMF/digitalmars oplink but the COFF/microsoft linker. if the dmd config file sc.ini is set up properly, and you don't call the linker explicitly but compile in one go by just calling dmd, you only have to add '-m64' as command line argument to switch from 32bit.exe to 64bit.exe.

[dejlek]

Yes, -m64 will produce COFF and use Microsoft linker AFAIK

[thewilsonator]

All one needs to do is copy the python36.lib (or other version) from $PYTHON_INSTALL_DIR\\libs\\ along with the DLL in to a directory on the library path and adjust "libs-windows-x86_64" : "directory" accordingly.

I'll do a PR for 3.6.

@Laeeth : do you need any other versions of python?

[firoozye]

@thewilsonator More generally, Python 2.7 is used widely. Fortunately, we don't use it, but a lot of people do dev work for 2.7, so if 64-bit 3.6 and 2.7 can be dealt with in one fell swoop, I would definitely recommend.

[atilaneves]

@thewilsonator Copying isn't the right solution. After all, regular distutils requires no copying - the required python .lib file is linked in automatically. It "just works". The issue is that PyD monkey patches distutils and that information is lost. See my PR.

[atilaneves]

@firoozye Handling Python versions explicitly isn't the way to go - distutils for C and C++ just works, no matter where Python is installed, what architecture it is (32 vs 64) or what version.

[Laeeth]

@thewilsonator @atilaneves @firoozye yes - we need python 2.7 also. and I think Atila is right - we need to make it so it just works, and consistently so. Ie someone just specifies pyd as a dependency in a dub project and it works. @atilaneves please also make sure ppyd (John project) works.

[ariovistus]

@atilaneves fix is deployed to 0.10.2, anyone care to confirm it works?

[ariovistus]

why is code.dlang.org not updating? is there something wrong with my versioning?

[atilaneves]

@ariovistus Your versioning looks fine to me, I don't know what the issue is.

[atilaneves]

@ariovistus Should you or I send an email to Soenke about the versioning? It seems to have gotten worse somehow - currently the latest version on code.dlang.org is 0.9.9!

[wilzbach]

I think the dub or dub-registry issue tracker is the best place for reporting this irregularity.

[andre2007]

code.dlang.org shows now 0.10.5

[tastyminerals]

Any updates on this?