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.
Related
I'm trying to compile an OpenGL program using Visual Studio 2013, but I get the following error:
Error 1 error LNK1104: cannot open file
'freeglutd.lib' ...
For reference, I have FreeGLUT installed and have configured VS to search the correct directories for the include files and library files. Indeed, VS recognises the GLUT include files just fine. I've also added opengl32.lib and freeglut.lib to the Additional Dependencies.
Why is VS looking for 'freeglutd.lib'? It's definitely not listed in the Additional Dependencies. I can solve the compilation error by renaming 'libglut.lib' to 'libglutd.lib' and removing the former from the dependencies, but I'm just curious why it's behaving this way.
Speaking of Additional Dependencies, is adding opengl32.lib actually necessary? I can compile my (very basic) program without it, but more than one person has said it's required, perhaps for older versions of Visual Studio?
if you check the freeglut_std.h (freeglut V3.0):
/* Link with Win32 shared freeglut lib */
# if FREEGLUT_LIB_PRAGMAS
# ifdef NDEBUG
# pragma comment (lib, "freeglut.lib")
# else
# pragma comment (lib, "freeglutd.lib")
# endif
# endif
so if you don't define NDEBUG, the linker will link to "freeglutd.lib",
you can solve that by defining a NDEBUG in "PreprocessorDefinitions".
Good luck!
Hey man I don't know if you're still having this error but here is a solution. Pretty much the "freeglutd.lib" has to do with debugging, hence the "d" on the end, so what I did was go into the:
Properties > C/C++ > Preprocessor > Preprocessor Definitions and type NDEBUG. Then OK and Apply.
What this does is in the "freeglut_std.h" there is a ifdef for NDEBUG that if it is defined then use "freeglut.lib" otherwise it's going to use the "freeglutd.lib". So by defining it in the Preprocessor Definitions, you are now using the "freeglut.lib". Hopefully this helps you out!
Possibly already answered: freeglut error LNK1104
Also two things to check for:
Are you building in debug or release mode? The d at the end of freeglutd.lib suggests that it's a library meant for debug builds
Try creating a new project from scratch, put some basic runnable code in it that uses freeGLUT and see if VS is linking properly. This will also verify if for some reason the project file of the previous project was corrupted (as #RobertHarvey suggested) or the problem is somewhere else
I solved this problem by compiling freeglut and freeglut_static from generated CMake soluton in Debug mode - freeglutd was created in the lib/Debug directory. You can put this directory into lib path then and it will work!
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.
Please help me on the gcc compiler command
gcc -c -ID:\pjtName\lib -c -fprofile-arcs -ftest-coverage D:\pjtName\source\tmp.ada
I am trying to compile the tmp.ada with coverage. adb and ads files are located in D:\pjtName\source folder. and my lib files are located in D:\pjtName\lib folder.
The problem is gcc is not locates tmp.ads file and the library files in the D:\pjtName\lib folder. it show file not found error
after this command i need to run gcov command for the tmp.ada file
GNAT’s build process is complicated. gcc is really too low-level a tool to use easily; instead, use gnatmake and GNAT project files.
You’ve tagged gnat-gps, so I assume you actually have GPS. If that’s so, your best bet would be, when opening GPS, to select Create new project with wizard and go on from there. If you get stuck, use GPS’s included help or come back here.
To get coverage information with GPS, you go to Edit / Edit Project Properties and
in the Ada tab, select Code coverage and Instrument arcs, which includes -ftest-coverage and -fprofile-arcs;
in the Ada Linker tab, select Code coverage, which includes -fprofile-generate (you get link time errors otherwise).
By the way, you mention a file tmp.ada; it’s best to stick with .ads for specs and .adb for bodies. GNAT does its best, but if your other code includes with Tmp; GNAT will look for tmp.ads. You can alter this behaviour, but why bother unless you have to for other reasons!
As was stated above, don't use gcc.
I usually use gnat compile filename.adb then use gnat bind filename.ali, then gnat link filename.ali -Lexternaldirectory -lexternallib
I am currently digitizing old VHS cassettes. For post-processing, I would like to implement a custom algorithm with C++ & OpenCV. I have already implemented a promising prototype in Matlab, but it can only process single images (reading / writing video files is not possible in my version (R2010a); also, Matlab is far too slow).
Sadly, I am - over and over again - stuck with CMake. Though I wonder ... this can't be so difficult. I have often had problems with CMake, so I will go into a lot of detail here. I hope that you can not only point out to me what I am doing wrong here, but give general advices towards my usage of CMake as well. Maybe I am doing it all wrong, I don't know.
Here is what I've done so far:
I have downloaded the OpenCV 2.3.1 superpack from sourceforge. The superpack contains OpenCV source code, includes and - most importantly - the .lib and .dll files for all major platforms. For this reason, I need not build OpenCV myself. It is already done. I need only use/link it.
I installed (i.e. extracted to) the superpack in C:\dev\vs2010sp1_win32\opencv\2.3.1.
I have renamed C:\dev\vs2010sp1_win32\opencv\2.3.1\OpenCVConfig.cmake.in to OpenCVConfig.cmake.
I have created a folder for my project C:\dev\VhsDejitterizer with the following structure:
VhsDejitterizer/
CMakeLists.txt (A)
src/
CMakeLists.txt (B)
libvhsdejitter/
CMakeLists.txt (C)
vhsdejitter/
util.h
util.cpp
main/
CMakeLists.txt (D)
main.cpp
Here are the contents of the individual CMakeLists.txt files.
/CMakeLists.txt (A)
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT("VhsDejitterizer")
CMAKE_POLICY(SET CMP0015 OLD)
FIND_PACKAGE(OpenCV REQUIRED
NO_MODULE
PATHS "C:/dev/vs2010sp1_win32/opencv/2.3.1"
NO_DEFAULT_PATH)
ADD_SUBDIRECTORY("src")
/src/CMakeLists.txt (B)
ADD_SUBDIRECTORY("libvhsdejitter")
ADD_SUBDIRECTORY("main")
/src/libvhsdejitter/CMakeLists.txt (C)
UNSET(source_files)
FILE(GLOB_RECURSE source_files "*.h" "*.cpp")
ADD_LIBRARY(libvhsdejitter STATIC ${source_files})
TARGET_LINK_LIBRARIES(libvhsdejitter ${OpenCV_LIBS})
UNSET(source_files)
/src/main/CMakeLists.txt (D)
UNSET(source_files)
FILE(GLOB_RECURSE source_files "*.h" "*.cpp")
ADD_EXECUTABLE(main ${source_files})
TARGET_LINK_LIBRARIES(main libvhsdejitter ${OpenCV_LIBS})
UNSET(source_files)
Configuring and generating the Visual Studio .sln (...) files works well. In fact, I am not getting a single warning or error:
Configuring done
Generating done
However, my attempt to build the 'main' project in Visual Studio fails:
1>------ Build started: Project: main, Configuration: Debug Win32 ------
1>Build started 04.04.2012 14:38:47.
1>InitializeBuildStatus:
1> Touching "main.dir\Debug\main.unsuccessfulbuild".
1>CustomBuild:
1> All outputs are up-to-date.
1>ClCompile:
1> main.cpp
1>LINK : fatal error LNK1104: cannot open file '#CMAKE_LIB_DIRS_CONFIGCMAKE#/libopencv_gpu.so.#OPENCV_VERSION##OPENCV_DLLVERSION##OPENCV_DEBUG_POSTFIX#.lib'
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.59
========== Build: 0 succeeded, 1 failed, 2 up-to-date, 0 skipped ==========
Further details:
Operating system: Windows 7 Pro 64-bit
IDE: Visual Studio 2010 SP1
CMake version: 2.8.4
Target platform (i.e. what am I compiling/building for): Windows 32-bit
My questions:
How do I successfully build the 'main' project? I.e. how to fix that error?
What are these #VARIABLE_OR_SOMETHING#? I have tried to find out where they come from, and they seem to be set up in OpenCVConfig.cmake. But how are they supposed to work? Are they supposed to be evaluated by Visual Studio at "build-time"? If so, how are they evaluated?
You have probably noticed that I have set up quite a sophisticated folder structure. Do you have any advice on this? How do you organize your libraries and projects? Are there best-practices? Where are they documented?
Thank you and best regards, Robert
These variables are probably related to CMake's configure_file command, which allows you to specify a parameterised template document (typically with the extension ending in .in) and you can substitute CMake variables into the file to create it. They are evaluated at the time of the configure_file call, which happens when running CMake. I think what's happening is that there will be a parent CMake script to the one that you've taken which will configure that file with the contents of those variables and then use it in an add_subdirectory call. I would suggest checking for any readme that describes the top level run process (or any file which defines those variables then substitute them manually).
I have fixed it now. I think I can safely say that the whole mess was not my fault. Sorry for answering my own question.
Here is what I tried first (of course, this did not work for me, but it might work for others):
As Martin Foot pointed out in his answer, the *.in files are templates which are supposed to be filled out with proper values during a CMake configuration. However, I am using the OpenCV superpack, which includes all the binaries. For this reason I have, at no point, performed such a configuration step, because I assumed this would only be necessary if you wanted to compile something.
However, it seems that - even if you're using the superpack with prebuilt binaries - you have to configure the project in order to get your OpenCVConfig.cmake generated. Vadim Pisarevsky has stated that in the OpenCV bug tracker.
For some reason, this didn't work for me. I started up the Cmake GUI as usual, pointed it to the OpenCV directory and hit "Configure". I even hit "Generate" out of desperation. Yet, no OpenCVConfig.cmake appeared.
So I had to go on further ...
This is what actually helped:
In a recently filed bugreport related to OpenCVConfig.cmake, Sergiu Dotenco pointed out "that the currently provided OpenCVConfig.cmake is pretty fragile" etc. etc. Fortunately, Sergio has also provided a custom FindOpenCV.cmake script. By using his script I have finally been able to generate a working Visual Studio solution.
By the way, this is my current top-level CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT("VhsDejitterizer")
SET(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake-modules" ${CMAKE_MODULE_PATH})
SET(OPENCV_ROOT_DIR "C:/dev/vs2010sp1_win32/opencv/2.3.1")
#SET(OPENCV_USE_GPU_LIBS ON)
FIND_PACKAGE(OpenCV REQUIRED)
ADD_SUBDIRECTORY("src")
I have installed Sergio's FindOpenCV.cmake script in a new cmake-modules/ subfolder of the project. It is also important to note that I am using (as opposed to my original setup, where I used the "config mode") the minimal FIND_PACKAGE variant ("module mode"). Only if the minimal variant is used, CMake is looking for Find<package-name>.cmake scripts in the CMake module path. See the CMake documentation for FIND_PACKAGE.
I have also found this guide, which is about how to properly use CMake if you're a library developer: http://www.vtk.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
I have fixed it now. I think I can safely say that the whole mess was not my fault. Sorry for answering my own question.
You fixed it?
I am having the same problem, and I followed your solution but it did not work.
When CMake executed the command
FIND_PACKAGE( OpenCV REQUIRED )
It would output:
One or more OpenCV components were not found:
calib3d
contrib
core
features2d
flann
highgui
imgproc
legacy
ml
objdetect
video
CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
Could NOT find OpenCV (missing: OPENCV_CALIB3D_LIBRARY
OPENCV_CONTRIB_LIBRARY OPENCV_CORE_LIBRARY OPENCV_FEATURES2D_LIBRARY
OPENCV_FLANN_LIBRARY OPENCV_HIGHGUI_LIBRARY OPENCV_IMGPROC_LIBRARY
OPENCV_LEGACY_LIBRARY OPENCV_ML_LIBRARY OPENCV_OBJDETECT_LIBRARY
OPENCV_VIDEO_LIBRARY) (found version "2.3.1")
Finally, I used the commands
include_directories
TARGET_LINK_LIBRARIES
to include all necessary directories or files, and it works, in a awkward way!
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