ROOT v6 on Windows 64-bits

ROOT 6.14 runs on Windows 32-bits. Is it planned to provide a 64-bits version in a near future?

1 Like

Well, in the future yes, but not sure about near… The main issue is the long type on Windows 64 being 32 bit (thanks MS!), and casting pointers to long doesn’t work anymore. And the gdk (GUI and graphics) layer might not even compile on Win64… So quite some work ahead

1 Like

For us it is very important to get to 64 bit too! The memory limitations and inability to use so many libraries which are provided only as 64 bit versions are really bad.
Is it possible to get rid of the pointer casting completely? It is not a very good strategy anyway :stuck_out_tongue:

I agree, but this would require several changes in the interface. And maybe even some backward incompatibilities…

What is the status here: when I tried 64-bit building on ROOT5 to gain some insight on what would be needed, CINT seemed to be the worst problem. But also the badly specified Long_t/Long64_t mess caused problems that were not trivial to fix, e.g. simply typedefing intptr_t as Long_t caused other problems in 64-bit build. Based on a quick look ROOT is still missing (u)intptr_t types [1] and it continues to cast pointers to Long_t so non-CINT problems might have even gotten worse since ROOT5, but are there any other concern regarding 64-bit Windows build apart from these?

[1] As far as I know, casting pointers to longs is and has never been correct C++ in the sense that nothing in the language guarantees sizeof(long) would be equal to sizeof(void*); that’s why some people use (u)intptr_t types and have portable software.

1 Like

I agree with you, that’s why it will take some time to fix…

As I said, some internal parts of ROOT might not compile (e.g. GDK)…

Hopefully the interpreter is not included in those. Having core ROOT without graphics etc. (or perhaps just without one graphics backend?) as Win 64-bit build might be a good (development) start.

Nope. Cling compiles and works on Windows 64 since quite a while already. And the major (and most intrusive) issue is really the casting of pointers to Long_t

What about casting (memcpy) pointers to double instead? We have to do it to use Minuit2 minimizer - to send as one of the parameters (defined as fixed) the pointer to the interfacing class.

I would prefer to go for a proper (clean) solution (and interface)

Yes, replacing one bad method with another is not wise in the long run :slight_smile:

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.