Following is my linking command:
Running Mkbootstrap for XML::SAX::ExpatXS ()
C:\Perl\bin\perl.exe -MExtUtils::Command -e chmod -- 644 ExpatXS.bs
link -out:blib\arch\auto\XML\SAX\ExpatXS\ExpatXS.dll -dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl\lib\CORE" -machine:x86 ExpatXS.obj -def:ExpatXS.def
Creating library blib\arch\auto\XML\SAX\ExpatXS\ExpatXS.lib and object blib\arch\auto\XML\SAX\ExpatXS\ExpatXS.exp
The compilation flags used are /Zi /GF /MD -c
I want to know if this dll is getting statically or dynamically linked. I referred http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx but the compiler ignores these options when I specify them in my makefile.
Thanks
Your snippet only shows the DLL getting built, it doesn't say anything about the program that uses the DLL. Which has the choice to use the DLL either way.
If you have no idea then a simple way to find out is to run Dumpbin.exe /imports on the EXE. You'll see the exports from the DLL that are actually used listed in the output. If you don't see anything then the DLL could only be dynamically loaded. Or not at all. The debugger shows notifications for DLLs that get loaded into a process, you'll see them in the Output window.
Download a copy of the windows Dependency Walker, fire it up and load your freshly minted dll.
It will show all the DLLs that your dll imports. If one of the imports has a name like msvcr<blah>.dll (e.g., msvcrt.dll, or msvcr90.dll — you get the picture), then it is using the c-runtime in a dll (which incidentally, is the recommended thing for a dll to do).
Related
I have a custom library that utilises this code (https://www.dropbox.com/s/iwft7snjmntf160/SoASpriteFont.zip?dl=0).
The linked code was written for Visual Studio; I am using CodeLite on Windows.
Its has a SpriteFont.cpp that uses fprintf.
The static library that has SpriteFont as part of it compiles fine on its own and produces a *.a quite happily.
However when I use SpriteFont via other code, I get a linker error (if I am not mistaken):
D:/Coding/TDM-GCC-32/bin/g++.exe -o ./Debug/tmp #"tmp.txt" -L. -L../deps/lib/ -L../bengine/lib/ -lbengine -lSDL2_ttf -lSDL2main -lSDL2 -lopengl32 -lglew32
D:/Coding/TDM-GCC-32/bin/../lib/gcc/mingw32/5.1.0/../../../libmsvcrt.a(dsnos00619.o):(.text+0x0): multiple definition of `fprintf'
../bengine/lib//libbengine.a(SpriteFont.cpp.o):D:/Coding/TDM-GCC-32/include/stdio.h:243: first defined here
I have read all over and found some similar situations but nothing that I have managed to use to resolve this.
It sounds like there is an issue with the way TDM-GCC redefines fprint in its' stdio.h, but I can't see how. Upon further examination, I believe the problem may lie with SDL_ttf, which is used by SpriteFont.
Also, I have tried using other functions from stdio.h and they compile fine; problem only seems to be fprintf
I have tried to create a barebones program to illustrate the problem. Hope it helps. Hopefully the fact it is a CodeLite project won't be a source of irritation.
If I can provide more info or code please ask.
This usually happens in MinGW when linking against a dll file that also has file in the form of <NAME>.dll.a
To fix this, just link against the dll directly (I recently encountered the same problem when build LLDB debugger on Windows /w MinGW, the solution was to link directly against the dll file and delete the dll.a file
is there a tool in windows SDK to ckeck what CRT a library uses?
for example I have a *.lib file, how do check if it's compiled with /MDd flag or /MT?
also how to check the same for dll or exe?
can this be done with dumpbin?
If it is a .lib file, a static link library, then you don't know anything about the CRT yet. It wasn't linked yet. You can find out about the original programmer's intention, use a hex viewer to look the .lib file, Notepad will do fine as well. You'll see the original command line that was used to compile the .obj files that were embedded in the .lib file. Simply search for "cl.exe", you'll have a good idea what compiler version was used from the path to cl.exe. And you can see the command line options so you'll know if /MD or /MT was in effect. And the /O option, important to have an idea whether you've got a Debug or Release build.
If it is a .dll file then dumpbin.exe /imports is your best choice. The dependency on the msvcrxxx.dll file will be visible, with xxx the version number like "120". If you see it then the name tells you if /MD or /MDd was used, "d" is appended for the Debug version of the CRT If it is missing then you know that /MT or /MTd was used, no hint about the build flavor available.
Following the recommendations from the library owner is always best, you can get into a lot of trouble when the CRT version or build settings of the library doesn't match yours. With non-zero odds that you have to ask him for an update, YMMV.
I am using dev c++ IDE which used ming gcc(i am not sure of it)
I wanted to use sqlite3 in my win32 c application
I downloaded sqlite3.dll and sqlite3.dev and used dlltool to create a .a file like libsqlite3.a and pasted in the lib folder of dev cpp and added this path in the project options -> parameters
i copied the header file sqlite3.h into the include folder(which i got from another website - http://www.opensource.apple.com/source/SQLite/SQLite-74/derived_source/sqlite3.h)
i executed the program and got the message 'the program can't start because sqlite3.dll is missing in your computer'
so i copied the sqlite3.dll into my working directory and then it worked
BUT
How to make the sqlite.* static while compiling?
I mean i thought by including the libsqlite3.a, the final exe will not be dependent of any external dll's.
So i want to know how to compile in a way that i will not be needing a dll and by doing so it makes my windows program standalone.
do i have a create a .lib file instead of .a file?
EDIT after answers and comments:
Besides, the devpak is working fine... yet i wanted to know how to include files to project or to create .a files so i am trying this way because if some components do not provide devpak then this will be the way we need to compile.. isn't it?
EDIT to show what i have done after the answer by CL and the two comments
This is how i have added the sqlite.c to project list
Here is the compile log
Compiler: Default compiler
Building Makefile:
"C:\Users\jayapalc\Documents\test-sqlite\Makefile.win"
Executing make...
make.exe -f "C:\Users\jayapalc\Documents\test-sqlite\Makefile.win" all
g++.exe -c sqlite3.c -o sqlite3.o -I"lib/gcc/mingw32/3.4.2/include"
-I"include/c++/3.4.2/backward" -I"include/c++/3.4.2/mingw32" -I"include/c++/3.4.2" -I"include"
sqlite3.c: In function `void strftimeFunc(sqlite3_context*, int,
sqlite3_value**)':
sqlite3.c:14727: error: invalid conversion from void*' tochar*'
The files i got in sqlite.org/sqlite-amalgamation-3071502.zip are
shell.c, sqlite3.h, sqlite3.c, sqlite3ext.h and i saw in other discussions that shell.c is not needed...
Besides, people were talking about gcc and g++... .
Apart from updating Dev-C++ itself, try this to compile sqlite.c as a C file:
Go to Project >> Project Options >> Files.
Find the C file we're talking about. Untick "Compile file as C++".
This should inform Dev-C++ that it should invoke gcc.exe, and not g++.exe.
If you don't want to compile sqlite yourself by adding it to your project, you can try passing the -static flag to GCC/G++ to force it to link libsqlite.a statically.
Just include the sqlite3.c file in your project.
You need only this filed, and it must be compiled as C, not C++.
Apparently, Dev-C++ does not allow mixing C and C++ source files in one project.
Instead, you could try to compile sqlite3.c as C and then include the generated .o file into the C++ project (on the Linker page).
I am trying to run FFTW code in a mex file. This is strictly for the purpose of development and testing. After some googling, I see that others have tried to do something similar and have had related problems, but I have not found any solutions. When attempting to run the mex file, Matlab tells me:
??? Error using ==>
chirpTransform.mxCta Invalid MEX-file
'\removed\my\directory\+chirpTransform\mxCta.mexw32':
The specified procedure could not be
found.
.
I am using gnumex with MinGW to build the mex file because LCC seems to have some issues. I have tried using the 32 bit DLL from the FFTW site (http://www.fftw.org/install/windows.html). I have tried using the fftwf3.dll in the Matlab 2009b bin directory. I built the dll from source using Msys/MinGW. In all cases, the results are the same. In all cases I did the following to generate the lib file.
c:\gnumex\mexdlltool.exe -d
libfftw3f-3.def -D libfftw3f-3.dll -l
libfftw3f.lib --as C:\MinGW\bin\as.exe
I also tried using the visual studio lib.exe tool and experimented with various mexdlltool flags.
It appears that I can directly call functions in the fftwf3-3.dll using Matlab's loadlibrary functionality. Since the DLL appears not to be the problem, I tried building a static version of fftwf3 and linking it directly into the mex file. I got the same results! If I remove the FFTW code, the mex file runs fine. I have just about given up at this point, and I am tyring to come up with alternative methods of testing.
I've run into this issue with other mex functions. In my experience, it typically means that there is a dependency issue. Some dependency is not located.
Here is a link to TMW's documentation on this issue:
Invalid MEX-File Error
Give it a read, and then try using dependency walker to diagnose the problem.
It's been a long time, and my setup has changed, but this works for me now. I suspect hoogamaphone was right. I probably didn't have the fftw dll in the same directory as the mex dll (and it wasn't in my path). In fact, 64 bit Matlab 2016a still gives you a warning about not being able to find the mex file when, in fact, it's a dependency that's missing.
My current setup is using the Visual Studio 2013 C++ compiler by default. As mentioned on the fftw web site, you need to generate a lib file for linking. You can run the Visual Studio command prompt from a regular command prompt like so:
"%VS120COMNTOOLS%VsDevCmd.bat"
Then run the following in the directory with the def file.
lib /machine:x64 /def:libfftw3f-3.def
And compile.
mex mxCta.c cta.c -I../fftw -L../fftw -llibfftw3f-3.lib
Perhaps another possibility is that gnumex introduced some dependency into the mex dll. I no longer recall whether I had used gnumex successfully testing other code. When using cygwin, if you don't use the mingw compiler (x86_64-w64-mingw32-gcc), you'll end up with a dependency on the cygwin1.dll.
Finally, if you use more than one compiler, make sure all the compiler flags are the same (same function calling conventions, ABI, etc). Also, Mathworks has changed the mex build procedure. In a recent project, I copied mexconfig.xml to my local directory from
C:\Users\myuser\AppData\Roaming\MathWorks\MATLAB\R2016a\mex_C_win64.xml
and edited the compiler flags like so:
COMPFLAGS="/Zp8 /GR /W3 /EHs /nologo /MD /Gz /TC"
If you use a custom build file, use the -f option.
mex mxCustom.c custom.lib -f mexconfig.xml
I have a simple C DLL that exposes functions from a static library. The DLL compiles without errors and I can run DUMPBIN on it to see the exports. However, when I attempt to load it with DllImport in C#, it says this:
System.DllNotFoundException: Unable to load DLL 'ei.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E).
It's in the correct directory, for sure. So, I read that it might be a good idea to try Dependency Walker, in case I need to include something else. Unfortunately, when I try to open my DLL in DW, I get this:
Error: At least one file was not a 32-bit or 64-bit Windows module.
Here's my cl command:
set ERL_INTERFACE_DIR=C:\Progra~1\erl5.7.2\lib\erl_interface-3.6.2\
call vcvars32.bat
cl /I%ERL_INTERFACE_DIR%include /LD ei.c ei.lib Ws2_32.lib /link /LIBPATH:%ERL_INTERFACE_DIR%lib
What could be causing this?
I was linking with a LIB file whose name is the same as the LIB file that the compiler emits, so it was linking with itself. I just changed the name of my source file to ErlInterface.c. I would think the linker would throw up a warning or something when this happens, but it doesn't.
Anyway, I can open the DLL in Dependency Walker now, but I still can't use it with DllImport. That's for another question, though.