Hi,
We have been using a program which was linked against root 5… which was working for quite a long time. Some month ago we changed the code and are now linking against root 6… which is working, too.
Now we recognized, that the program seems to be working only, on that PC on which it was built, which is a small desaster. (before it was working)… so I have some questions:
What is needed on a PC to run a program linked against root (except from root ) - is it necessarry to use exactly the same root-version?
In VS the linker options contain the ROOTSYS variable. What is, if the Path is different from the machine where the code was build, and the code is running?
Is VS needed on the machine, where the code is running, or is the RuntimeEnvironment sufficient?
How tolerant is the executable against changes of the version of VS, the RuntimeEnvironment, SDK …?
Has anyone ever thought about creating a static link (so that a root installation is not needed anymore on the executing PC??)
Not necessary, but it’s impossible to predict, since Visual Studio change/update something like every week or so, and if they fix bugs, they also introduce new ones sometimes…
ROOTSYSmust always point to the location of where ROOT has been built/installed
Since the interpreter use Jitting (just in time compilation), the development environment is needed (for the Visual Studio and Win10 SDK include directories)
That was not my question:
on my compiling PC if have ROOTSYS=c:\root_v6.22.00 and I am using the varibale %ROOTSYS% to feed the linker. In the executing PC I have ROOTSYS=c:\Programs\root (which is correct for this PC),.
Is the variable somehow resolved during the linking? So does ROOTSYS need to be exactly the same path on all executing PCs?
Ok - but if I do not run root for itself, I’m using only the executable which was linked before against the root-dlls?? What are the prerequisites for that PC? I guess that binary needs to now the paths for the header and the paths for the dlls?
This is one error message I’m getting frequently when running my exe
Sorry, let me be more clear (hopefully): ROOTSYS must always point to where ROOT is located, on any computer, independently of where ROOT was built. I can be different on every computer, and must be independent on where ROOT was built. If it’s not the case, please open a Github issue.
Correct. ROOT might still use the interpreter internally, which needs the system include PATH
Try with a more recent version of ROOT, some of those incompatibilities might have been fixed
You must have ROOT installed, Visual Studio with Windows 10 SDK (same versions is preferred), and then ROOTSYS must be set and %ROOTSYS%\bin added to the PATH (or call root\bin\thisroot.bat every time before running the application executable…)
Well, I just tried with Visual Studio v16.10.4 and Windows 10 SDK 10.0.1.19041.0 and ROOT v6.24.6 works jus fine…
BTW, did you start ROOT (or your application) from a x86 Native Tools Command Prompt for VS 2019?
If not, can you try?
Good! But I don’t understand why you didn’t have it already, since this should be automatically selected when choosing the Desktop development with C++ in the Visual Studio Installer…
It was pretty hard for me to acquire some acceptance for an open source software like root in an international company. When I was using root5 and creating executables linked against root 5 the world was much easier.
Yes, you can tell the users please install this software from cern and this tool will work. To tell them please install root6 and visual studio 2015 professional is an order of magnitude more complex due to the licensing situation of vs.
To tell them: please use this 80KB tool and install the 3GB studio and root in exactly this version, is impossible. I cannot guarantee which version is installed due to centralized updates. It is impossible to not run into a ‘no-so-simple-to-solve-version-mismatch’.
I would like to ask you for two (from my point of view) necessarry things:
Be much more precise with the prerequisites. Not only vs 2019, but also version of the sdk, what components are really needed. I will not need python in a lot of cases e.g. Which mismatches between build-machine and executing machine are allowed?
Try to find an “out-of-the-box” solution. E.g. put the core-essentials like file-io, TTree, histograms and stuff like this into a core runtime environment. Make a minimal root runable without visual studio (why not using the Runtime Environment)).
the company is regulating what kind of software the users are allowed to install. They are regulating the check-boxes in the setup, too.
Due to licensing reasons we are not allowed to use the community version
Who said that Visual Studio professional is needed? I don’t use Visual Studio professional, we use the free version (Community)
That’s impossible. we cannot test all possible versions of Visual Studio with all versions of ROOT (as I said, the version of Visual Studio change every week or so)
I don’t know what you mean by “using the Runtime Environment”. And I could try to bring that in a team meeting, but not sure that re-engineering the core of ROOT for Windows users would be easily accepted
In another hand, this kind of issue should be automatically solved when the C++ modules will work on Windows. Maybe @Axel or @vvassilev can comment on this
Stay with the much smaller and easily “embeddable” ROOT 5, if you can.
Switch to using “containers”. Inside, you can have a Linux environment, with ROOT 5 or 6 and anything else you need (the problem now is that Docker started to ask money for their “desktop” tool on Windows, but maybe there exist ways to deal with it).
Sorry, it wasn’t my intention to ‘bite’. Its just really disappointing to see that there is no user-friendly (user in the meaning of having really no clue of programming) solution to install root on windows.
some answers:
I’m not the guy from the legal department, but as far as I do understand, we are not allowed to use the community version.
Yes, I see this point
But, that’s not what I meant.
I also mixed up some software packages here. Of course there is no runtime for C++, Maybe you can explain me more in detail what components of Visual Studio and SDK are really needed?
I guess headers and dlls are coming with the SDK, is the compiler needed for running root? What else?
Isn’t there any possibility to provide a minimum Windows root release that only needs some basics? (e.g. SDK without vs)
Yes, that was my solution for the last 8 years or so… and then root was back on windows…
this is definitely the last solution… not again please
We also had that thought using containers. I’m not sure how much easier this is for the users. I have never tried it out. Another idea was to create a centralized Windows PC for users to logon via remote login
I cannot be of much help on Windows but, the ROOT Team provides “ROOT Docker containers”, so you can start to play with them without much additional hassle. In a long run, I think it will be much easier to maintain “containers” than fight against “native” Windows utilities.
Another alternative could be to use WSL, which is part of Windows, so it’s more acceptable to IT, it just needs to be activated (if your machine is not too old, I suppose, and can run VMs, although WSL is not a VM); with Ubuntu (also coming from MicroSoft, installed via the MS store or from a PowerShell terminal) it uses about 2 GB of drive space plus any packages you may add, of course, so it’s much less than VS and all the things that may or may not be needed but have to be installed because we don’t know. This setup could be prepackaged in the images deployed by your IT, and installation after-the-fact is not as simple as with ROOT 5 but I think is still OK, as long as the steps are clearly written; this way you can use the latest ROOT. A couple of possible obstacles:
WSL 1 and 2 don’t provide a GUI, so if you need to open any graphics (inside that Linux) you have to install an X server on Windows (e.g. Xming or VcXsrv), which IT may not like;
I think you don’t get interactivity between Windows and Linux software (e.g. probably can’t run ROOT from a script on Windows, but I haven’t tried). Linux, however, is able to access the Windows filesystem (it is automatically mounted).
Finally, these two may not be issues anymore with the new WSLg, which provides native access to the GUI (so no need to install an X server) and allows to run Windows software from within Linux. As far as I know, WSLg works on Windows 11 but not on Windows 10, but it might at one point.
Well, requiring end-users to install and maintain WSL may end up in a mess. Just imagine that the main application developer upgrades his WSL and / or ROOT version and / or some libraries. Then all these changes would need to be “propagated” to all end-users (and, of course, you cannot prevent them from modifying their WSL instances by themselves at any time, just for fun).
So, I still think a “container” is a better solution. Whenever the main application developer changes anything, end-users will simply get a new “bundle” in the form of a single file.
Moreover, one could easily maintain several “containers” (e.g., the “dev”, “new”, “pro”, and “old” versions of the application), which internally may use completely different versions of ROOT and other libraries (and compilers).
Note that the same “container”, without any modifications, could also be run / tried on other operating systems (e.g., Linux).
Of course, one could also imagine that the application is delivered in the form of a “virtual machine” (Windows can run them fine), but this will again create many unnecessary additional problems.
) - is it necessarry to use exactly the same root-version?
