changed compile methods and now external dll cant be instantiated
-
Hello all,
I've looked for quite some time today on an issue we have with development. our project is coded in c++ 11
We recently moved to autotools to compile our project (cross platform). the problem we have exists with our windows exe release (compiled in linux with autotools). Before autotools we had used qmake and mingw32 etc which didn't cause the issue we face.
Since we have moved to autotools to compile the project windows exe cannot access our external VB.NET dll file (dll can no longer be instantiated by QAxObject with autotools -- note the qt libs are static libs in our release we only have one dll external). It is only affected by the new compiling method we use to make it easier to build and release our project that is cross platform.
The dll file we use is a VB.NET dll strictly used on windows versions of our project.
I'm confused as to how the exe cant find the dll file that is in the program files folder with the released exe. its a stand alone dll.
anyone have any ideas?
-
Hi
I would inspect the DLL with
http://www.dependencywalker.com/one from old way and one from new way and see if anything changed.
Just as a note. even u changed the make tool. its same compiler as before ?
-
I have done so. the only difference between compile methods is
before qmake -> makewith autotools is using configure autogen then does a make i suppose technically same thou its slightly different as we compile all the dependencies except the windows vb dll. the vb dll has all the dependencies for it with it in the program files as well.
For example if i simply take the autotools exe and place it in a directory where the old compile method was done it should still work completely fine. the dll is registered and in the program files.
you start the old compiled method exe in there and it loads the vb dll without issues but when u load the auto tools exe version it cannot instantiate .
if it works with one it should work with the other but it does not. I been looking at dependency walker (which is grossly out of date and throws lots of misinformation on win7). the autotools exe actually has far less warnings or errors then the originally compiled method. even without the dll present the windwos software can run without issues just dont get the features it offers. may have to figure out if QAxObject is some how different from old method versus autotools compiled method where it statically puts the libs in.
-
Hi,
Out of curiosity, why change from qmake to autotools since qmake allows you to generate projects for all supported platforms ?
-
It was a developer choice as a upstream project to us eventually moved to it for easier distribution.
Before we compiled for windows with mingw32 on a disk image on windows and then for all other platforms we have another guy doing the PPAs etc.
we moved to autotools so that it can all be done on linux etc. It wasn't my decision but our upstream of our project moved to that method a long time ago and we slowly updating to that effect.
-
but again i just find it strange because the dll is compiled in visual basic and it separate from the program . I dont get how QAxObject would have trouble init the dll with a autotools exe. the program is not dependent on having it but its a features part that need it if they are to be used. the code there has not been changed and unfortunately the error messages about not init is not giving any details as to why. with no code changes just compile method changes this shouldnt be an issue. the dll is called BoincStake.dll and anyway heres the section of code that makes it work for the old method but not new.
printf("Instantiating globalcom for Windows %f",(double)0); try { globalcom = new QAxObject("BoincStake.Utilization"); printf("Instantiated globalcom for Windows"); } catch(...) { printf("Failed to instantiate globalcom."); } bGlobalcomInitialized = true;globalcom is static QAxObject *globalcom;
-
-
forgot one more thing. the autotools was done also to include all the qt static libraries in the exe to reduce the amount of files being installed for the application. basically all we got to install is the exe and the vb dll and itss dependencies.
@iFoggz Normally I would say this is because you mixed compilers but since it's a COM component it shouldn't matter.
My recommendation here is to use procmon to see what is happening when it tries to open the com object. You can get procmon from microsoft's website now-a-days.
Also, is there any qDebug output on the console at all? A lot of times when there are issues with something like that Qt will print debug messages on the console in a debug build.
-
Since you mention that you are using a static build of Qt. Did you also use the qmake from that static Qt to build your project ?
By the way, beware of the licensing constraints that comes with the use of a static Qt.
-
defiantly found something interesting with process monitor.
It pulls the CLASS ID from the registry and when i look in the registry at that location it is reading a completely different result then in that specific key then it tries to open Program Files\our app folder\that class id instead of the DLL strange behavior for that exe. never seen it pull incorrect data from registry that is not even in the registry as that. and that CLSID does exist thou elsewhere in registry for the dll which is weird. i think i'ma try to see if i can use CLSID instead and hopefully it points to the dll thou in a perfect would I would be able to QAxObject("c:\programfiles\appfolder\BoincStake.dll") and it'll enter at the Utilization point
-
defiantly found something interesting with process monitor.
It pulls the CLASS ID from the registry and when i look in the registry at that location it is reading a completely different result then in that specific key then it tries to open Program Files\our app folder\that class id instead of the DLL strange behavior for that exe. never seen it pull incorrect data from registry that is not even in the registry as that. and that CLSID does exist thou elsewhere in registry for the dll which is weird. i think i'ma try to see if i can use CLSID instead and hopefully it points to the dll thou in a perfect would I would be able to QAxObject("c:\programfiles\appfolder\BoincStake.dll") and it'll enter at the Utilization point
@iFoggz COM is awful.. Gotta be one of the worst things Microsoft ever created. It doesn't surprise me that is happening at all.
You can try registering your component (in your directory) with regsrv32 as well.
But at least you know your problem now. It should be fairly easy to solve.
Do keep in mind the license issues @SGaist mentioned. If you aren't using commercial licenses for all your developers you can't use the static linkage.
