I am building the Poco libraries from source code using cmake, following the instructions from the official website, on OSX High Sierra.
From that I get a bunch of files representing the dynamic libraries with extension *.dylib for example libPocoJSON.23.dylib.
However an external application is looking (in the same path locations), apart from the files created with the build, for other files of the library with a similar name such as to the created ones (they are different only for a d appended to the first part of the name). One example of such file is:
libPocoJSONd.23.dylib
I have found that these files are created with the debug build (while the release build creates only the files without the d extension).
How to perform the build of the debug? Should I look for a flag to active in any of the cmake file or it is a complete different source code?
How to perform the build of the debug?
Use cmake -DCMAKE_BUILD_TYPE=Debug
See CMAKE_BUILD_TYPE for details.
Related
We are compiling a library with CMAKE under Linux which is then installed per default under /opt/mylib and its sources are placed in this folder as well.
When users try to debug with GDB the library sources are not found by GDB automatically.
How can we compile the library that GDB finds sources without specifying anything?
For example the C++ standard library works like that. I can debug an application and I do not have to tell GDB where to find the sources.
Note: This question is not about how to make GDB find the sources (I know how to do this) but how to adapt the CMakeLists.txt and the compile process that it is not necessary to manually specify the source directory in GDB.
You are likely looking for the -fdebug-prefix-map=old=new GCC flag.
From the manual:
When compiling files residing in directory old, record debugging information describing them as if the files resided in directory new instead. This can be used to replace a build-time path with an install-time path in the debug info. It can also be used to change an absolute path to a relative path by using . for new. This can give more reproducible builds, which are location independent, but may require an extra command to tell GDB where to find the source files. See also -ffile-prefix-map.
The "may require an extra command" part applies if you want to debug as-built binaries without installing them. Debugging installed binaries will just work (TM).
I use find_package(HDF5 COMPONENTS CXX REQUIRED) in my CMAKE script to load the include directories and libraries of HDF5. Cmake tells me
Found HDF5: C:/Program Files/HDF_Group/HDF5/1.10.0/bin/hdf5_cpp.dll (found version "1.10.0") found components: CXX
And generates my visual studio solution.
I also use the library stored in ${HDF5_LIBRARIES} ${HDF5_CXX_LIBRARIES} for my target, but when I try to build it, I get a Linker Error LNK1107 saying that for file hdf5_cpp.dll:
invalid or corrupt file: cannot read at 0x380
which I think is due to the fact that visual studio is trying to directly link against the dll file instead of against the lib file which is in another folder, namely in:
C:\Program Files\HDF_Group\HDF5\1.10.0\lib
Question: Is this a bug in FindHDF or did I configure something wrong?
I have not used hdf5 on windows for some time, but I do recall there being a bug that causes it to link against the dll instead of the lib.
you should manually set (either via the command line cmake -D method, or via the cmake gui)
HDF5_hdf5_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5.lib
HDF5_hdf5_cpp_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5_cpp.lib
etc. - or just
HDF5_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5.lib
HDF5_cpp_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5_cpp.lib
depending on whether you have an older or newer version of FindHDF5 (they change the library var names in newer versions - check the ones used to make sure you get them right - I'm doing this from memory so might have made a mistake)
EDIT:
If the option of manaully specifying the libs is a problem, then there is the option of using FindPackage(HDF5 NO_MODULE) if your hdf5 library was compiled using cmake generated makefilesetc.
When using NO_MODULE, the find package scripts will bypass the findhdf5.cmake script and look for the HDF5Config.cmake or hdf5-config.cmake file that is placed in the relevant subdir of the hdf5 build/install folfer.
This is cross platform friendly and is supported by all newer hdf5 versions - provided they were built using cmake and not ./configure ...
I'm following a book written for the older version of OpenCV (OpenCV 2 Computer Vision, by PACT) and it tells me to include the lib folder in my Visual Studio 2013 Property Manager when creating a new property sheet.
I don't see a directory called lib in the current GitHub version (opencv-master, which is OpenCV 3.1.x). Has this folder been replaced by something else?
I built OpenCV with cmake. I found a 4 year old unanswered question wherein someone was also looking for this folder. They tried building the library from another directory that no longer exists, but that didn't work for them anyway...
Another OpenCV user just told me that GitHub doesn't include the libraries, so you have to cmake them locally. I'm still not clear on where / how I can cmake them.
I realize the pre-built binaries have this, but I'm avoiding them because I need the SURF functions in opencv_contrib, so I needed to build it from source.
The pre-built binaries will have a library folder in the corresponding path
Local System Path(Opencv Folder)-> build->x64/x86->vc10/vc11/vc12->lib.
As you mentioned that you don't wish to use it then the only option left for you is to build it locally which is a much better option if you plan to use Opencv libraries for varied functions and projects as it resolves many build errors that you might face later.
I used the Cmake Graphical user interface to build opencv, following are the steps I followed to successfully build the libraries on my system .
So, you would need to create a new folder that will contain all
the Makefiles generated.
Please refer to this image for clearer understanding:
In GUI you define source directory path where OpenCVConfig.cmake is present, according to your image it's the
current folder in your image opencv-master.
Similarly, define the path to the new directory you created where all the build files would be stored.
Make sure to uncheck Build_Examples to avoid configuration errors.
Then click Configure at the bottom when configuring is done .(you may need to configure it twice)
After click the tab adjacent to configure, Generate to create the solution file.It will ask you for the compiler name
select the
compiler installed on your system from the list of choices. After
generation is done.
Go to this path Build_New_Directory(the directory you created) you will find OpenCV.sln build this project, it will take around 10-15 minutes depending on your processor, wait patiently .If you get a build error at this point don't invest your time in debugging on Visual Studio go back to Cmake GUi and configure it again and this time give the path to dependent libraries on your system that it could not find .Repeat the process it should be successfully build now.
After it is successfully build you can now locate the path of all opencv libraries build on your system as follows.
Build_New_Directory(the directory you created)->
install->x64->vc10(compiler I used)->lib.
As an update to Nikita's awnser:
There is a cmake build bug where the x64 folder will not be created if OpenCV_RUNTIME is not set. This will happen if you build an old OpenCV (e.g. <= 3.2.0) with a newer Visual Studio Version than was available at that time (e.g. Visual Studio 2017)
To fix this, add the correct MSVC_VERSION elseif-cases in both ./cmake/OpenCVDetectCXXCompiler.cmake and the ./cmake/templates/OpenCVConfig.root-WIN32.cmake.in (or ./cmake/OpenCVConfig.cmake in < v3.2.0) files:
[...]
elseif(MSVC_VERSION EQUAL 1900)
set(OpenCV_RUNTIME vc14)
# old version ends here with endif()
elseif(MSVC_VERSION GREATER 1909 AND MSVC_VERSION LESS 1920)
set(OpenCV_RUNTIME vc15)
elseif(MSVC_VERSION GREATER 1919 AND MSVC_VERSION LESS 1930)
set(OpenCV_RUNTIME vc16)
endif()
[...]
I am using a library installed via cmake in Xcode, and I'd like to allow my debugger to step through that library's code while debugging my application.
After building and installing the dependency cmake project, the cmake project that depends on it would then include that one. When it is run I'd like to step through the code of the dependency library with the Xcode debugger.
Is there a way to tell Xcode for my main application where the headers, source and debug built binaries (if necessary) of the library are so I can step through?
I've found a few relevant questions, but none provides straightforward instructions for configuring your library's source to be found in Xcode with support from the GUI.
LLDB equivalent of gdb “directory” command for specifying source search path?
In Xcode, how to debug with external libraries that you have the source for?
Xcode equivalent of Visual Studio's “Find Source”
Here is an example homebrew formula which installs a cmake project and enables the debug symbols. I can come up with an example that uses the library if needed as well.
If you are linking to the debug version of the library into your application, and you haven't moved or deleted the .o files you used to build it or the source files for those .o files, then you shouldn't have to do anything. lldb will pick up from the loader the location of the library's binary, and that will have a "debug map" that points to the .o files (where, on OS X, the actual debug information is stored) which lldb will then read, and the debug information will contain the path to the source files.
So some part of this chain must have gotten broken if you aren't seeing source in Xcode when you stop in some code in your library.
First make sure you really are building the debug version of the library (the compile lines that build the .o files should have -g in them.)
Next, if your make process is deleting the .o files or stripping the library before installing it, then lldb won't be able to trace from the binary to the debug info. The easiest way to fix this is to make a dSYM as part of the build process, using the dsymutil utility, and install the dSYM somewhere lldb can find (next to the library, or in any location Spotlight searches) or add it explicitly with lldb's add-dsym command. Note if the library is getting stripped you need to make the dSYM before it gets stripped.
Finally, if you are moving the source files from where they are when built, then you can use the source-map as described in the first of your links.
I'm developing an application using Qt and OpenGL, and found it necessary to download the GLM library. It's a header-only library, so I don't need to link to anything. I want this application to build on any system that has the correct libraries installed. My problem is that I don't know where to put GLM so that the system can find it without adding a specific path to the project's .pro file. The .pro file is part of my git repository, which is how the source is distributed to other systems like Linux, etc. So I don't want this file to specify the exact location of GLM because other systems could have it in other places.
I'm currently developing on Windows, compiling in Qt Creator using Visual C++ 2010. I read from MSDN that #include <file> searches using the INCLUDE environment variable, so I tried to add the path to glm.hpp to INCLUDE, but QtCreator's build environment for this project seems to overwrite INCLUDE. So I appended the path to GLM to the new INCLUDE from within QtCreator's Projects tab, but my code still can't find glm.hpp.
In general, how can I add an external library to my system such that my compiler will be able to find it without specifying the exact location in a project file that's distributed to other systems?
What you need is a build system with the power to search the system for the libraries you request, and be able to do so on any platform. One such build system is cmake, and it is the most widely used build system. In essence, cmake allows you to write a build script in which you can specify all the things you normally specify when creating a project in Qt Creator or Visual Studio, like the list of source files, grouped by targets to compile (libraries, executables, etc.), the relative paths to the headers, and libraries to include for linking and for include-paths, amongst many more things. For libraries that are installed on the system, there is a function, called find_package() (part of cmake script commands), that will find out if the library is installed and where to find its lib files and headers (storing those paths as cache strings that you can specify on the targets and such). It usually works great, as long as the libraries are not installed in weird places. The way it works is that when you run cmake, it will generate a build script/configuration for almost any platform you specify, and then you use that to compile your code. It can generate makefiles (Unix-like or windows), CodeBlocks project files, Visual Studio project files, etc.. And many IDEs also have native support for cmake projects.
I wish I could recommend an alternative, just to sound less biased for cmake, but I haven't heard of any that truly compare to it, especially for the purpose of locating external dependencies and working with different platforms. I would guess Boost.Build is decent too.