Windows stand-alone with ROOT libs: TCanvas problem

Hello ROOTers,

I have a Windows 7 application I have built against parts of ROOT 5.34/09. Works great on my machine, but of course, I have ROOT installed on my machine. I’m using MSVC 2012.

I want to be able to distribute this application to a second machine without installing ROOT. (MSVC 2012 is also on the target machine.) I have found all the libraries on which the application depends, and I can get it to launch, but I get no TCanvas and instead get the errors of:

Warning in TCanvas::ResizePad: theCanvas width changed from 0 to 10
Warning in TCanvas::ResizePad: theCanvas height changed from 0 to 10

Now, in other forum posts, I see this is a configuration problem during ROOT install. I was hoping to work around this by defining ROOTSYS and putting the libraries into the PATH. No joy. I have even gone so far as to copy over the entire ROOT area from my machine to the target (without build/install) and I can launch ROOT, and do “new TCanvas” and get a graphics window with no errors. I can graph functions on the target, from a ROOT session, with no problem. But the standalone application won’t launch a TCanvas (it will do all the other things it is designed to do).

Does anyone know how I might get past this problem short of installing and building on the target? The opening snippet of my main file is below, and as I say, it works on my personal machine.

int main (int argc, char* argv[]) {
// ROOT setup
TApplication theRootApp(“theRootApp”,&argc,argv);
theRootApp.SetReturnFromRun(kTRUE);
TCanvas *theCanvas;
TGraphErrors *g;

// This line causes the errors on the target machine
theCanvas=new TCanvas(“theCanvas”,“theCanvas”,1200,600);

// Etc…

Hi,

ROOT needs ROOTSYS, with some of its subdirectories, like $(ROOTSYS)/etc, for configuration and plugins; $(ROOTSYS)/bin, for executables and DLLs; $(ROOTSYS)/include, for header files; and maybe some other, but you can already try with these ones.
And “%ROOTSYS%\bin” has to be in your PATH

Cheers, Bertrand.

Hello Bertrand, thank you for your response.

Yes, ALL of those things are in place, as I bit-by-bit copied over more and more of the ROOT installation from my machine until I had copied the entirety of it. ROOTSYS has been defined since the beginning, and both %ROOTSYS%\lib and %ROOTSYS%\bin have been in the PATH since the beginning. No joy. ROOT works and can do a TCanvas, but the standalone, for some reason throws and error and won’t launch a TCanvas.

Other attemps, like putting all the .dll files into the same directory as the .exe have been fruitless as well. What could be wrong?

 - John

Hi John,

What is the exact error you get?
And BTW, naive question: Are you sure the standalone application has been built with the same version of ROOT than the one you are copying over?
And could you rebuild the standalone application on the target machine? (just for testing purposes)

Cheers, Bertrand.

Hi Bertrand,

The exact errors are listed in the first post.

Yes, I could rebuild, and will try to find time to do that today, but that entirely defeats goal of distributing an executable.

 - John

[quote=“jkrane”]Warning in TCanvas::ResizePad: theCanvas width changed from 0 to 10
Warning in TCanvas::ResizePad: theCanvas height changed from 0 to 10[/quote]Those are not errors, simply warnings abourt the canvas size (consequence of the original error…)

To me these messages mean a serious ROOT misconfiguration -> the usual reason is the nonexistent / improper ROOT’s “etcdir”.

If those do not count as errors, then there are no errors. The code successfully runs indefinitely, but without the TCanvas, pointlessly.

The configuration is correct when I actually run ROOT at the command line, but fails for the standalone code. So how can the configuration tell one executable from another? For what it’s worth, the directory structure is identical in both machines too.

After writing the above paragraph, I was able to get the code to make a TCanvas by physically putting it in the ROOTSYS\bin directory. At least now I can start deleting the ROOT files chunk by chunk until I have a minimal codebase for the standalone to run.

It would be nice to know why this is happening. I will post my minimal code set when I have it, in case it is useful to somebody else.

From my experience having ROOTSYS-variable pointing to ROOT-path and %ROOTSYS%\bin in PATH in the environment of the running process has been enough to get standalone ROOT app working in Windows (I’ve used .bat-file to set variables and launch the actual application). Can you confirm that the running application has correct ROOTSYS and PATH (e.g. with Process Explorer)? Have you tried setting higher value to gDebug to see if it would provide an insight about the problem?

Those things are easy to check from the command line and they are set correctly. ROOT works fine, but the standalone does not, without some heroics.

Trying to trim the ROOT files down to the smallest workable size is not going quickly.

Are you able to set the gDebug to a higher value in the beginning of main to see if it reveals anything? I haven’t found any documentation about it’s values, but e.g. value 10 should be (more than) enough.

As near as I can tell, my dependencies are:

1 - my application (.exe), and the libraries I deliberately link (libCore, libGraf, etc.) which will explicitly throw an error if not present

2 - Etc directory: root.mimes, system.rootc, and the plugins subdirectory, with a list of 14 plugin sub-sub-directories

3 - Fonts directory: FreeSans.otf, FreeSansBold.otf, symbol.ttf

4 - Icons directory: arrow.xpm, arrow_*.xpm

5 - lib directory: libHistPainter.rootmap

%ROOTSYS% must be defined. The stuff in item 1 must be in the %PATH% or same directory as the .exe file.

With the above, I do not need to install ROOT on the target machine. Total install is 31.5 MB and 68 files, compared to 371 MB and 4878 files for the ROOT install alone. Other executables that use more than just draw TGraphErrors, TF1, and TLegend will no doubt need more. The difficult things to determine were the plugins and the .rootmap file, which do not fail/warn of the missing elements by name.

 - John