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.
Related
I am trying to link glfw on windows.
On Linux it was fairly straight forward:
dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"
sourceFiles "deps/glfw/build/src/libglfw3.a" platform="posix"
libs"Xi" "pthread" "X11" "Xxf86vm" "Xrandr" "pthread" "GL" "GLU" "Xinerama" "Xcursor" platform="posix"
If I try to link with a .dll on windows, dub tells me that Error: unrecognized file extension dll.
dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"
sourceFiles "deps\\glfw\\build\\src\\Debug\\glfw3.dll" platform="windows"
If I try to link with a .lib, dub tells me that COFF is not supported.
dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"
sourceFiles "deps\\glfw\\build\\src\\Debug\\glfw3.lib" platform="windows"
GLFW was built with vs2013. What do I have to do differently?
There's three cases here:
Default 32 bit Windows build. dmd on Windows, by default, builds 32 bits using the old OMF linker format. You cannot link straight to a dll and need a .lib. But since it uses the old format, most .libs provided won't work - you have to make your own.
(lol i want this in the list item but markdown sucks. whatever)
Download this thing to get implib.exe: http://ftp.digitalmars.com/bup.zip
and use that to make a .lib from the .dll: implib /s yourdll.lib yourdll.dll and try to link with the new lib. (Add it to the files list like you are already doing)
If it doesn't work, try the command again, but this time without the /s switch.
It should work by then.
-m32mscoff 32 bit builds. With that flag to dmd, it will output a 32 bit program using the new COFF format instead of the old omf format. For it to work, link.exe in your path MUST be the Microsoft linker, from Visual Studio, instead of the default Digital Mars optlink.exe (which, confusingly, was also called link.exe until recently. That was nice when it was a compatible replacement for the Microsoft one.... twenty years ago...).
Anyway, if you have the Microsoft C++ compiler and linker installed and put that link.exe in your path, dmd -m32mscoff should work using existing .lib files from the dlls.
TIP: If you used the Windows installer for dmd, open the "D2 64 bit command prompt" from the start menu to get the path set up. It will tell you to use -m64, but you can also use -m32mscoff from that environment and it should work. if everything installed properly.
-m64 64 bit builds. Basically the same as the mscoff switch - you need the Visual C++ linker in your path - but does 64 bit instead of 32. Of course, this requires a 64 bit dll and lib to be there too.
In the comments, it sounds like you might also be facing some bugs, I don't know about that, the above is if everything else is working properly.
I used to use GDB + Clang, and I'm realizing how much I took stack traces for granted.
How does one have Waf generate PDB output in the directory of a built executable?
My configuration passes /Zi and /debug flags to the compiler/linker, but the only pdb file I'm seeing (for any of my several binary outputs located in subdirectories of my build directory) is a vc110.pdb file in the root of the build directory (and no, there's no executable binary of any kind in the root of my build directory).
Extra information available on request - even after some Googling and other info-finding tasks I'm just not sure what would be useful for me to put down at the moment (as in, I'd probably need to dive into the Waf code to know what the heck to put down...).
The debugging database is only generated my Visual Studio if you request it. Run the build again with python waf.py -v -v build to see what switches Waf sends to VS.
link.exe should be given /DEBUG and to cl.exe /Zi and /FS. You set them in your wscript using:
def configure(ctx):
...
ctx.env.CXXFLAGS += ['/Zi', '/FS']
ctx.env.LINKFLAGS += ['/DEBUG']
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).
Based on this excellent tutorial, I am able to build the boost library without problems. However, I cannot find any PDB files are generated.
boost_1_49_0>b2 --prefix=c:\temp\boost1.49 --toolset=msvc-10.0
--build-type=complete
Since I have built .lib and .dll files for boost. what else minimum build I should do in order to get all corresponding pdb generated?
From "Built in Features"
When you call b2 try using --debug-symbols=on
You can build pdbs for static libs directly in the necessary directory (which may be needed for the debugger) by a little tweaking of msvc.jam. Find rule archive there and change
PDB_NAME on $(>) = $(<[1]:S=.pdb) ;
to e.g.:
PDB_NAME on $(>) = "c:\\Lib\\boost\\stage\\lib\\$(<[1]:S=.pdb:G=)" ;
(Disclaimer: I have only a vague idea what that cryptic expression means, never saw it documented anywhere, it was a pure guesswork on my part, hence no guarantees, but it works for me).
PDBs for DLLs are built by the linker, so you may set its option in e.g. project-config.jam:
import toolset ;
using msvc ;
toolset.flags msvc.link LINKFLAGS <link>shared : "/PDB:c:\\Lib\\boost\\stage\\lib\\" : unchecked ;
I'm sure there's a way to get the output directory from the system automatically. If anyone figures that out, please update.
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