Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make/os_win sets BIT variable to 64 always #1614

Closed
syclik opened this issue Sep 22, 2015 · 1 comment
Closed

make/os_win sets BIT variable to 64 always #1614

syclik opened this issue Sep 22, 2015 · 1 comment
Assignees
Labels
Milestone

Comments

@syclik
Copy link
Member

syclik commented Sep 22, 2015

This doesn't run on Mac. We should either set this conditionally or leave it off.

@syclik syclik self-assigned this Sep 22, 2015
@syclik syclik added this to the v2.8.0++ milestone Sep 22, 2015
@syclik syclik added the build label Sep 22, 2015
@wds15
Copy link
Contributor

wds15 commented Sep 27, 2015

Hi!

In SHA: 82b9fe6 I am propsing a fix to the problem. This patch sets the BIT variable to 32 on 32bit machines and to 64 on 64bit capable windows OS.

The logic is taken from

http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx
and
https://msdn.microsoft.com/en-us/library/aa384274(VS.85).aspx

The thing is that on 64 bit windows machines the variable PROCESSOR_ARCHITECTURE may be set to x86 as for a 32 bit machine, but this is due to the fact that the process is a 32 bit process (32bit process run on 64bit windows). However, only when a 32 bit process runs on a 64bit machine the extra variable PROCESSOR_ARCHITEW6432 is set.

I did test the change on win32 and it works correctly, I don't have a 64bit windows available - could someone with access to 64bit windows test that -m64 appears when compiling with g++? Thanks - then we can trigger the pull request.

@syclik syclik closed this as completed in 18ab9e0 Sep 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants