Native Windows 64-bit build?

ROOT
1

Dear ROOTers,

is there any way (yet) of getting root to run natively under the 64-bit versions of MS Windows? I am now using Windows 7 64-bit and the increased address space would come in handy for my analysis.
So far, I have neither seen binaries nor a “win64” build target. Is there any such thing under way?

Thanks,

Moritz

PS: It appears unlikely noone ever asked this before but I simply couldn’t find the respective posting. Sorry.

2

Hi Moritz,

Sorry, there is no Win64 binaries of ROOT, and nothing is foreseen in a near future.

Cheers, Bertrand.

3

Hi Bertrand,

thank you for the quick answer.
Is there any easy way I could build a Win64 version from source or would this require substantial changes?

Thanks,

Moritz

4

Hi Moritz,

It requires quite a lot of changes in ROOT itself, but also in other libraries used by ROOT…
If it was easy, it would be already done and available :wink:

Cheers, Bertrand.

5

Yeah, that’s what I was fearing…

Thanks anyway,

Moritz

6

Hi, I would like to ask if there are any news regarding the native Windows 64-bit ROOT build. Is the situation the same as ~1/2 year ago or is there any “light at the end of the tunnel”?

Thanks for update. 64-bit version of ROOT on Win would be great help for me.

7

Hi,

Unfortunately, the situation is still the same. But we will investigate what (and where) the changes have to be done. I cannot give any schedule yet.

Cheers, Bertrand.

8

Hi Bertrand,

Thanks for quick response. I’m glad to hear that the issue is being considered. I believe, I’m not the only one who would benefit from the 64-bit ROOT on Win. Unfortunately, the hardware we use has drivers under Windows only so I cannot avoid this system…

Regards,
Josef

9

I use ROOT for a couple of years. Now I’m in the need to port my application to 64 bit. Unfortunately it looks like ROOT is the only library I utilize that is not 64 bit ready on WIndows. Can you please tell me what things look like today? Will the problem be solved in near future?

10

Can you give me some hints on where the problems of a “native” 64 bit build are?

Do you think there is a chance to produce 64 bit DLLs using Mingw64 as a cross compiler with Linux - and less efforts compared to the “native” build?

11

Hi,

I’m investigating right now. There were some problems with bindexplib (extracting the symbols from the object files to generate the .def files) and now with rootcint… But if you want to make the exercise with Mingw64, feel free to go ahead! :smiley:

Cheers, Bertrand.

12

Hi Bertrand,
Please, is there anything new regarding the 64-bit build?

Cheers,
Josef

13

Hi Josef,

Not yet… But it will appear on the ROOT web page as soon as it will be available.

Cheers, Bertrand.

14

Hello,

I did a bit of research on this a couple of years ago. I presume some progress has been made since in terms of understanding the depth of the changes. The Win64 dev team decided to use a scheme for their 64 bit integral types which preserves the 32-bit compatibility of their legacy code. This means on 64 bit windows a long type is 32 bits. On many Unix systems a long is 64 bit (in 64 bit systems). This means that all the Long_t/ULong_t values in Root, CINT etc, must be inspected and upgraded to a well reasoned type which makes sense in both a 32 and 64 bit context. It’s a lot of work, and will require a significant testing period given the fundamental nature of the changes. I certainly look forward to learning what the ROOT team has learned of late.

Cheers,

Brandon

15

Bertrand,

could you please comment on the status of Windows 64 bit build? Can we expect a solution within the next couple of months? This feature is really important for me.

Thank you,
Andreas

16

Hi all, please, is there anything new regarding the 64-bit build for Windows? I have now pretty much all machines that I use running on Win7 64-bit. I am using root from Java and also Matlab that both is 64-bit and I need lot of memory. 32-bit Root is a major problem for me at this point.

17

As a comment related to the subject, it’s a peculiar detail that a project that carefully typedefs basic types such as int -> Int_t, float -> Float_t, then for an incomprehensible reason misses typedefs that could be considered the most important ones, namely the integer types whose size is equal to pointer types. Why I considered this worth mentioning is that based on quick look on the current code base, it seems that, at least partly, instead of fixing the problem, it’s just being pushed forward by switching ULong_t to ULong64_t(or is there any reason to say that assumption sizeof(int64) >= sizeof(pointer) today is any better than assumption sizeof(int32) >= sizeof(pointer) ten years ago?); for example the documentation of TExMap says:
“The (key,value) are Long64_t’s and therefore can contain object
pointers or any longs.”

Time for less future-brittle code with Intptr_t and UIntptr_t?

18

It is again couple of months, hence, please, is there anything new about the 64-bit version?

19

Hi,

No, and there is no real effort to do it right now. Any contribution is welcome (even if it is unusual for Windows users to contribute… :wink:)

Cheers, Bertrand.

20

Well, I’m Mac person :slight_smile: But I need to compile code for some Windows users too :confused: