If I do a LoadLibrary("msvcrt.dll") do I need to initialize the CRT somehow? Section 2 in the following document seems to say that I do, but I just get an undefined symbol error for _CRT_INIT when I try to call _CRT_INIT:
http://support.microsoft.com/kb/94248
Edit: I should have said that this is for a program that dynamically loads all the dlls that it uses, hence the call to LoadLibrary("msvcrt.dll").
Call DllMain() in it. If it relies on the C runtime, it will call CRT_INIT.
But a far better question is if a program is using something in msvcrt, there's no need to explicitly load the dll and initialize it, so why are you doing this?
If you're working in C++, have you declared _CRT_INIT as extern "C"?
Have you tried using the DUMPBIN utility ( http://support.microsoft.com/kb/177429 -- if you haven't your PATH up yourself, you'll have to use the Visual Studio Command Prompt I think) with the /EXPORTS switch to see which functions are available from the CRT DLL, just to double check?
If you get stuck, VS2005 and earlier (and presumably later...) come supplied with the source code for the runtime library. For VS2005, this is in VC/crt/src, relative to the VS install folder. It looks like _CRT_INIT is the right name -- see crtdll.c and dllcrt0.c, and it's a C function.
You must not call _CRT_INIT() but call CRT_INIT() (if you really must)
The link you referenced refers to using CRT_INIT() only when "Using the CRT Libraries When Building a DLL", and even then it is only one of two alternatives; the first probably being preferable in most cases.
Related
I built Qt from source (dlls) and am trying to build an application that uses the Qt dlls. I don't have a lot of experience with C++ so I'm running into what I'm sure is a very basic issue.
My builds are failing on the includes with errors like so:
Fatal error: QNetworkProxy: No such file or directory
Here is the g++ command I am using (I also used -L to add the correct folder to the lib path, but that also didn't work):
g++ -l..\..\wkqt\bin\QtCore4.dll -l..\..\wkqt\bin\QtNetwork4.dll -l..\..\wkqt\bin\QtWebKit4.dll -I..\include -Ishared -Ipdf -Ilib -Iimage -o ..\bin\wkhtmltopdf.exe pdf\*.cc lib\*.cc image\*.cc shared\*.cc
I tried in Visual Studio as well (assuming it wouldn't build, but I wanted to see if I could at least include the Qt dlls from there properly) and I am getting the same errors. Am I doing something wrong with the way I am compiling with g++? If I am linking with the Dlls properly then what is the proper way to use Qt functions from my code?
To clarify, I am not looking for how to properly use Qt. My question is: what is the proper way to use functions defined in any Dll from native C++ code? I apologize if this is a very basic question, but I'm unable to find a clear answer on Google and I don't have any experience with C++ and including third party libraries for use from C++ code.
DLLs can be used by dynamicly loading them and calling their used functions.
to call the exposed functions first define their syntax in the begining
suppose function is syntax is
BOOL MyFunction(int a,char* pszString)
then define syntax
#typedef BOOL (WINAPI *PMYFUNCTION)(int a,char* pszString)
then make object
PMYFUNCTION pfnMyFunction;
and get valid pointer by calling GetProcaddress after loadlibrarycall
HMODULE hlib= Loadlibrary("c:\\Mylib.dll");
if(hlib)
{ pfnMyFunction = (PMYFUNCTION)Getprocaddress(hlib,"MyFunction"); }
Hope this helps...
My code is like this:
void some_func(void *source)
{
...
double *casted = reinterpret_cast<double *>(source);
...
}
This causes std::__non_rtti_object exception. Acording to stack trace, it is raised from __RTDynamicCast, which is (as far as i know) MSVC implementation of dynamic_cast.
This exception should occur with dynamic_cast, as the pointer comes from external library (probably compiled without /GR) and points to struct with several doubles. But I would not expect this with reinterpret_cast. Shouldn't it just change the type of the pointer, without any checks at all?
Notes:
my compiler is msvc120 (MS Visual Studio 2013)
project is compiled with /GR (enable run-time type information)
pointer "source" comes from external library (probably compiled without /GR)
I also tried static_cast with the same result
Non-reproducible.
Ah, i tried to rebuild whole project with all additional libraries and
the problem disappeared. Seems strange, because I never had a code
using dynamic_cast, so don't know what caused this. Also I already
tried to rebuild that project only (without other dlls) before.
Anyway, thanks for all help.
-- OP
It seems as that you need to recheck dll's order of build in your makefile (if you use such). I guess that the source from the external library you mentioned, comes from external library that is "higher" in the build tree than the library which your code resides. Try to see if your makefile properly works (maybe misses some triggers).
I am in the process of upgrading a Visual Studio 2010 project that targets the INtime RTOS. Code that performs casting operations fail to link. When investigating the "inline assembly" output files, it turns out that for some integer casting operations, VS2013 is generating assembly instructions to calls to __dtol3, __dtoui3, __dtoul3, __ltod3, and __ultod3. The problem is that the INtime libraries do not contain definitions for these functions. I've verified that VS2013 does the same for Win32 targets for both Debug and Release builds.
Is there a way to get VS2013 to stop generating generating calls to these functions?
You would need to disable SSE2 codegen, through use of the /arch option (use either /arch:IA32 or /arch:SSE).
Alternatively...(what follows is not officially supported; your mileage may vary; do this at your own risk)
Extract from msvcrt.lib the object that defines these functions, and link that object directly into your program. These functions are defined in the object named ftol3.obj; you can extract it using the lib tool:
=>lib /nologo /list msvcrt.lib | findstr ftol3
f:\binaries\Intermediate\vctools\crt_bld\SELF_X86\crt\prebuild\INTEL\dll_lib\ftol3.obj
=>lib /nologo /extract:f:\binaries\Intermediate\vctools\crt_bld\SELF_X86\crt\prebuild\INTEL\dll_lib\ftol3.obj msvcrt.lib
You may need additional objects, depending on (a) which functions you use and (b) what, exactly, the INtime libraries define. Again, this is not a supported way to use the Visual C++ runtime libraries, and it may or may not work for your particular use case.
possibly another way:
add compile option
/d2noftol3
this option is undocumented
Try create one of them __dtol3, __dtoui3, __dtoul3, __ltod3, and __ultod3, for ex.
extern "C" unsigned int _dtoui3(const double x) {
return (unsigned int) _mm_cvttsd_si32 (_mm_set_sd(x));
}
Make function externally visible and implement in one file.
Some info
I am converting my project to use DLLs and am trying to break apart my Singleton class to avoid using templates.
My class, LudoMemory, originally inherited from Singleton. I am trying to give it the functions to destroy and create itself now and have my main engine not rely on the Singleton.
I have written a simple destroy method like such:
LudoMemory *memory_Singleton = NULL;
void LudoMemory::Destroy()
{
LUDO_SAFE_DELETE(m_Singleton)
}
and upon running the program (no compiler errors) I recieve this error:
The procedure entry point
?Destroy#LudoMemory##SAXXZ could not
be located in the dynamic link library
LudoCore.dll
LudoCore is the project that LudoMemory belongs to. Why is this happening? How can I solve it?
you don't have multiple versions of ludocore.dll on your system, do you?
Procedure entry points errors usually mean: you compiled your project against ludocore.lib version x, and when running the program, it uses ludocore.dll version y, and version y does not define LudoMemory::Destroy().
Jacob's answer about multiple DLL versions seems likely.
Also, with some build systems, you must explicitly list which functions will be exported in a DLL.
Research your build environment, and see if you must provide a list of methods to be exported as an entry-point.
In Visual Studio build environment, also you could try by disabling the References in Linker Optimization Settings [ No(/OPT:NOREF)]
I'm compiling a trivial wxWidgets app on MacOS X 10.6 with XCode 3.2
The linker is return an error about the symbol _main being defined twice:
once in main.mm
once in the test_app.cpp file.
After I commented out the macro:
Implement_App(TestApp)
The error went away, compiled & linked and I was able to run the application.
I haven't found this anywhere so any ideas about this?
IMPLEMENT_APP is a macro used in wxWidgets to create an entry point to the program without worrying about whether the program will be compiled on Windows, Mac, *nix, or whatever. As a result of this, IMPLEMENT_APP has to define main (or its equivalent, such as WinMain).
You might find the IMPLEMENT_APP_NO_MAIN macro to be useful. Check the other IMPLEMENT_APP_XXX functions in wx/app.h, too.
This paragraph from the wxApp overview is a little helpful too:
Note the use of IMPLEMENT_APP(appClass), which allows wxWidgets to dynamically create an instance of the application object at the appropriate point in wxWidgets initialization. Previous versions of wxWidgets used to rely on the creation of a global application object, but this is no longer recommended, because required global initialization may not have been performed at application object construction time.