I am migrating may root application from 5.06 to 5.16 on winXP and am having some trouble. My application is a .DLL created with MSC+.NET 2003. When building it, I link with[ul]libCore.lib
It was necessary to add libRIO.lib when I moved to 5.16 - ok, thats fine.
The way I launched my application with 5.06 was:
root -l maingui.cpp
where maingui.cpp is
CMyGui *pm = new CMyGui(gClient->GetRoot(),800,700);
} CMyGui is a class in MyAnalysis.dll that derives from TGMainFrame; When I execute this script, root hangs in the gSystem->Load() call. Through shear luck, I found that if I added gSystem->Load(“libGui.dll”) before gSystem->Load(“MyAnalysis.dll”) the macro would execute properly and launch my application. The strange thing is: after I call gSystem->Load(“libGui.dll”) root prints out the message[quote]Note: File “c:\root\bin\libGui.dll” already loaded[/quote]Can somebody please explain to me what is going on? Is there an application migration note?
We are aware of the difficulty of jumping across several production releases (in your case 5) and nor reading the Release Notes :
We always recommend to use the script in $ROOTSYS/bin/root-config to see the list of libs required
root-config -cflags --glibs (compiler flags and default libs)
PS: NEVER use gROOT->Reset in a named script
I have removed gROOT->Reset() from the named script.
I have read the release notes, in particular, the 5.16 notes WARNINGS section. I believe that what I reported is consistent with these note: my DLL was linked with all of the required libraries (including libGUI.lib, see original post from 7-Dec) however my script hangs when I execute
UNLESS I first execute gSystem->Load(“libGUI.lib”) which, oddly, produces the message
Note: File “c:\root\bin\libGui.dll” is already loaded
It appears as though I am doing everything correcly.
I am building my project with msvc++.net 2003. When I type root-configs – glib (from cygwin window), I see [quote]-MD -GR -GX -G5 -I’c:\root\include’ -include:_G__cpp_setupG__Net -include:_G__cp
p_setupG__IO -include:_G__cpp_setupG__Hist -include:_G__cpp_setupG__Graf1 -inclu
de:_G__cpp_setupG__G3D -include:_G__cpp_setupG__GPad -include:_G__cpp_setupG__Tr
ee -include:_G__cpp_setupG__Rint -include:_G__cpp_setupG__PostScript -include:_G
__cpp_setupG__Matrix -include:_G__cpp_setupG__Physics -include:_G__cpp_setupG__G
ui1 ‘c:\root\lib\libCore.lib’ ‘c:\root\lib\libCint.lib’ ‘c:\root\lib\libRIO.lib’
‘c:\root\lib\libNet.lib’ ‘c:\root\lib\libHist.lib’ ‘c:\root\lib\libGraf.lib’ ‘c
:\root\lib\libGraf3d.lib’ ‘c:\root\lib\libGpad.lib’ ‘c:\root\lib\libTree.lib’ ‘c
:\root\lib\libRint.lib’ ‘c:\root\lib\libPostscript.lib’ ‘c:\root\lib\libMatrix.l
ib’ ‘c:\root\lib\libPhysics.lib’ ‘c:\root\lib\libGui.lib’[/quote]I am linking with these libs and more (libThread and libMinuit). I do not have any of the linker directives (-include:_G__cpp_setupG__Net, etc) - is this necessary for building a .DLL that I subsequently load with gSystem->Load()?
This is a known Windows issue.
Your DLL (in fact the OS) load libGUI and in the same time, the autoload mechanism in Root try to load it too. So it hangs, according to this:
Every DLL has a special function called DllMain(). It’s called when the DLL is first loaded and when it is unloaded, and it takes care of initialization and then cleanup. Until it has run, the loader (part of the operating system that controls interactions between running code) will not let any other function in the DLL run. We say that DllMain holds a loader lock. This lock will also not let any other DLL be loaded while a DllMain is in process.
There are several actions that are not allowed inside DllMain. Neither the compiler nor the operating system will warn you if you perform these actions, and typically the end result of performing these actions is that your process will hang. You are not allowed to load another DLL, to access the registry, to call a function from another DLL (with the exeption of Kernel32.dll which is always available) or to touch another thread, including threads in other processes.
And when you explicitely load the DLL via gSystem->Load(“libGUI.lib”), the message comes from the auto-loader, telling you that the library has already been loaded.
Hope this explains the strange behavior.
If I understand you, you are saying that my DLL’s initialization code is trying to load a required DLL (libGUI.dll), but that is a forbidden operation. Ok, that explains the hang.
Something is still does not make sense: I add the gSystem->Load(“libGUI.dll”) before I load my own dll. The[quote]Note: File “c:\root\bin\libGui.dll” already loaded[/quote]message occurs BEFORE the gSystem->Load(“MyAnalysis.dll”) call.
Furthermore, if I type the following into the command line (as opposed to executing the script), there are no unexplained messages[quote]gSystem->Load(libGUI.dll)
CMyGui *pm = new CMyGui(gClient->GetRoot(),800,700)
[/quote]and everything works fine.
If I type in gSystem->Load(“libGui.dll”) at the command prompt and then execute my script, I get no “…already loaded” message and my gui fires up much quicker. Something is not quite right here…
Try to add:
gSystem->Load("MyAnalysis.dll"); And please let me know…
Yes, it works! I replaced my call to
and I get no unexplained messages. I should note that there is a still a bit of delay before my gui fires up - the CPU usage goes up to 100% for several seconds. If I do not execute the script on startup (I normally type root -l maingui.cpp) and manually type these lines, the total CPU time for root is about 1 second. If I execute the script, the total CPU time is about 3 seconds.
Thanks for you help!