I am using (for now) a trial version of Embarcadero C++ Builder XE2 Architect. I am working through migrating our current code from Borland C++ Builder 6.
There a some type libraries that I have been importing and installing into a package. So far the ones I have run into have imported just fine. However, I needed to import the OLE Automation 2.0 library. Upon doing this, I receive several errors, the first of which is mentioned in the title of this post.
The other libraries I have imported so far are: Crystal Reports ActiveX Designer Run Time Library 11.0 (craxdrt.dll) and Microsoft Jet and Replication Objects 2.6 Library (msjro.dll).
The following shows where the IDE says the problems are (file stdole_TLB.h):
typedef Stdole_tlb::IFontDisp IFontDisp;
typedef Stdole_tlb::IFontDisp *IFontDispPtr;
typedef Stdole_tlb::IPictureDisp IPictureDisp;
typedef Stdole_tlb::IPictureDisp *IPictureDispPtr;
The full parser context messages for those just show:
stdole_TLB.cpp(28): #include ..\9.0\Imports\stdole_TLB.h
stdole_TLB.h(56): namespace Stdole_tlb
I also receive another error message:
[BCC32 Error] stdole_TLB.h(254): E2029 'TDispWrapper<IDispatch>' must be a previously defined class or struct
Full parser context
stdole_TLB.cpp(28): #include ..\9.0\Imports\stdole_TLB.h
stdole_TLB.h(56): namespace Stdole_tlb
stdole_TLB.h(253): class IUnknown
That last one generates a lot of error messages so I think if that could be knocked out, most of the errors will go away.
Any help is much appreciated!
Related
I have a DirectShow filter (MonogramAAC encoder) successfully compiling. It also registers successfully, however, when I try to instantiate the filter in GrapheditPlus, it shows a CO_E_ERRORINDLL. After inspecting the filter properties under GraphEditPlus, the filter was actually linked to RegSvr32.exe instead of the actual host DLL!
Here's the evidence:
I'm sure the .def file in the linker is correct, I also tested that it IS being considered by the compiler and it is correctly pointing to the filter DLL.
A little bakground info:
I couldn't get the original project to compile under Visual Studio 2017 after automated conversion. (I couldn't resolve strange MFC and runtime library linker errors between the Monogram filter and the libaac.lib library, that I'm also able to compile successfully).
Finally I decided to recreate a brand-new VS2017 Project mimicking the original one and got it to compile and register (with the only warning being the mismatch between the Project name and the output library), but obviously I missed something important while recreating the project.
Any pointers?
Ok, I managed to find the reason for this unexpected behavior in this old post.
RegSvr32 just calls the DllRegisterServer entry point in your code.
What gets written to the registry is entirely up to your filter. If
you are using the standard baseclass call to AMovieDllRegisterServer2
as your DllRegisterServer, I would suspect that something went wrong
in setting up g_hInst, which should have been done by the call
DllEntryPoint in your DllMain.
…
The DllMain is not being called, so g_hInst stays 0 and
GetModuleFileNameA(...) returns the name of the currently executing
program instead of my filter.
The filter is using MFC (dynamically linked), and its DllMain() version is not calling the DllEntryPoint() function. I had to override the MFC DllMain() by adding extern "C" { int _afxForceUSRDLL; } as described in an answer to this question and call DllEntryPoint() myself to fix the registration problem. (I also found a missing #define was the reason for the property page not showing up).
After building with CMAKE for visual studio 2015, I found that there were some build errors that required me to edit the code. I feel that this should not be necessary and would like to know if I might have done something wrong in build process to make these errors surface
Firstly I had to correct the compiler name from vc130 to vc140 in the files include/CGAL/auto-link/auto-link.h and cmake/module/CGAL_GeneratorSpecificSettings.cmake. I assume that this is simply because it has not been tested VS2015 and someone just assumed that vc130 would follow vc120.
The other issue I ran into was that eight functions that did not compile. These were the functions
Segment_2<R_>::min
Segment_2<R_>::max
Segment_2<R_>::vertex
Segment_2<R_>::point
Segment_2<R_>::operator[]
Segment_3<R_>::min
Segment_3<R_>::max
The issue seemed to be that the type signature of the implementation did not match that of the declaration. I tried fixing the type signature, but was unable to get it to match exactly. To fix this I ended up moving the implementation of these functions into the declaration. I would like why this is apparently necessary as presumably it compiles for other people. Sloriot commented that it was because the VS2015 compiler was more recent than the one CGAL is tested with. It is however my understanding that the visual studio compilers are backwards compatible, an thus it should not break the code to update the compiler.
The first version of CGAL officially compatible with VS2015 will be CGAL 4.7.
It seems that the new version of the Microsoft has some issues compiling valid C++ code it was accepting before. This explains why the release 4.6 of CGAL (or prior versions) has some compilation issues with that new compiler.
I develop and maintain a very large opengl application, written using qt library. I'm switching from qt 4 to qt 5. I downloaded the qt 5.0.0 Windows (8) Visual Studio 2010 precompiled package. Unfortunately I discovered that I get millions of OpenGL errors caused by the OpenGL ES 2 support provided by the precompiled package. So, I downloaded the source code and I recompiled qt using the -opengl desktop flag on the configure step (for further details on the problem please refer here). The opengl compiler errors disappear but I still have hundreds compiler errors everytime inside the Qt library itself there is a reference to two macros Q_STATIC_ASSERT and Q_STATIC_ASSERT_X.
The typical kind of errors i get are:
- error C2062: type 'void' unexpected
- error C2238: unexpected token(s) preceding ';'
Some suggestions?
Thanks
As described in the comment to the question I solved the issue by looking for redefinition of static_assert and commenting it.
In particular my code was using the VCGLib library wich was redefining the assert in base.h
I don't get an error for this obviously erroneous code sample. Instead, qt creator mark var as unused variable. Is it possible to fix this strange behavior? I want semantic checking working.
Update:
I've been talking about on the fly semantic checking. Most IDE's analyse code as you type, and highlite errors. Qt Creator seemd to do some code analisis on the fly (because syntax highliting shows differently types, virtual functions and other things), but it doesn't hightlte errors at all.
The code model used by Qt Creator is pretty good but is not based on a complete abstract syntax tree for each compilation unit. Some information about it is provided in this Qt blog post:
http://blog.qt.digia.com/2011/10/19/qt-creator-and-clang/
AFAIK, the current code model allows Qt Creator to do semantic highlighting, refactoring, displaying type hierarchies etc. but does not allow a complete on-the fly check for potential compile errors (like yours). Since the syntax of your code is correct, Qt Creator does not show an error.
Very strange behavior. I tried to compile such code:
#include <iostream>
using namespace std;
int main()
{
UndefinedType val;
cout<<"Test"<<endl;
return 0;
}
On My Qt 4.8.1, 4.8.3 with MinGW on Windows7, in QtCreator 2.5.2, but in every case got error:
main.cpp: In function 'int main()':
main.cpp:7:5: error: 'UndefinedType' was not declared in this scope
main.cpp:7:19: error: expected ';' before 'val'
Please, provide more information about your build environment.
I'm reorganzing a legacy mixed (managed and unmanaged DLLs) application so that the main application segment is unmanaged MFC and that will call a C++ DLL compiled with /clr flag that will bridge the communication between the managed (C# DLLs) and unmanaged code. Unfortuantely, my changed have resulted in an Access violation that occurs before the application InitInstance() is called. This makes it very difficult to debug. The only information I get is the following stack trace.
> 64006108()
ntdll.dll!_ZwCreateMutant#16() + 0xc bytes
kernel32.dll!_CreateMutexW#12() + 0x7a bytes
So, here are some sceanrios I've tried.
- Turned on Exceptions->Win32 Exceptions->c0000005 Access Violation to break when Thrown. Still the most detail I get is from the above stack trace. I've tried the application with F10, but it fails before any breakpoints are hit and fails with the above stack trace.
- I've stubbed out the bridge DLL so that it only has one method that returns a bool and that method is coded to just return false (no C# code called).
bool DllPassthrough::IsFailed() { return false; }
If the stubbed out DLL is compiled with the /clr flag, the application fails. If it is compiled without the /clr flag, the application runs.
- I've created a stub MFC application using the Visual Studio wizard for multidocument applications and call DllPassthrough::IsFailed(). This succeeds even with the /clr flag used to compile the DLL.
- I've tried doing a manual LoadLibrary on winmm.lib as outlined in the following note Access violation when using c++/cli. The application still fails.
So, my questions are how to solve the problem? Any hints, strategies, or previous incidents. And, failing that, how can I get more information on what code segment or library is causing the access exception? If I try more involved workarounds like doing LoadLibrary calls, I'd like to narrow it to the failing libraries.
Thanks. BTW, we are using Visual Studio 2008 and the project is being built against the .NET 2.0 framework for the managed sections.
I believe I solve my problem. By systematically removing each library reference and
commenting out the calls to that particular library in the application code (unmanaged), I eventually removed the problem library and got the program to run. It's a brute force way of diagnosing the problem, and fortunately I didn't have to remove too many libraries to solve it. I'd still be curious if anyone has a comment if the library could have been identified though the debugger.
So, the next step is to move these library calls to managed code and pass the information back to the unmanaged side via my bridge DLL. BTW, I reintegrated the winmm.lib into the project and it still works.