I am trying to build a new release of my program, G4beamline. It uses Root libraries to read/write TNtuples to/from TFiles, and nothing else.
All topics in the forum about Windows 64-bit builds are ancient. Is there any hope?
Because of all the other libraries G4beamline uses, it is an enormous effort to go back to 32-bit builds. I’m not sure that it’s even possible.
BTW I already have it working on Mac and Linux.
The problem is that in ROOT, we cast pointers to long (or ulong) and on Windows 64, the long types are 32 bits (not kidding), so that would require quite an effort to port it to Win64, and we are not going to invest time in this, at least for ROOT 5. We will most probably find a solution for ROOT 6, once it compiles (and works) on Windows…
As a starter, would it finally be time to define and start using (U)Intptr_t so that ROOT would at least gradually get rid of the pointer-to-long conversions that are and, as far as I know, always have been wrong (i.e. that C++ standard has never guaranteed that long has the same size as pointer).
Yes, I know all that, but this will require a lot of changes (in the interfaces as well). As I said, that will be for ROOT 6 (or 7) only
Nice to hear that it’s known: the fact that not even the two typedef lines have been added RtypesCore.h just makes the development look so peculiar. Given that as a Windows user I’ve also missed 64-bit version and taken a look at the code if anything could be done (at least CINT-code said no loud and clear :)), it would be interesting to hear what has been the plan:
- Convert all Long_t’s to intptr_t etc.?
- Typedef intptr_t to Long_t and fix the overloads such as func(Long_T), func(Long64_T) or create a opaque Long64_t typedef?
- Something different?
I let @bellenot describe his plan - just mentioning that there is another ingredient which is gdk, which hasn’t even heard about Win64. I.e. porting the current Windows GUI library to 64 bit might be dramatic. But that’s sort of fine as we are planning to move into an entirely new GUI direction anyway… And again, Bertrand is the man for details
We’ll have to investigate the more efficient way to do it, without breaking other parts of the code. The Long_t and ULong_t types are not only used as pointer type holders…
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.