Hi I downloaded the latest boost library (.7z format) yesterday, after unzipping, I found there is no lib subdirectory here, so I cannot find any .lib files, is it the oversight of boost team?
The directory structure I have:
boost_1_51_0
boost
doc
libs
more
status
tools
etc
Most of boost's capabilities are in header only files inside the boost directory. Which means all you need to do is include the boost directory in your project and you're done.
For a few specific libraries you'll need to build your own lib via the instructions on Boost's site.
If you're using Eclipse with CDT (which is harder to configure) there are better instructions here.
Related
When you install many packages through vcpkg (such as vcpkg install cairo), at the end of this process, you are told what find_package and target_link_libraries CMake commands to use in order to link to the package that was installed. And this works fine; you can even re-execute the install command to see these CMake commands again.
However, some packages installed through vcpkg don't have these. After installing Pango for example, there is no list of CMake commands to actually use the library. I found the target CMake file for find_package in several of the vcpkg package directories, but the Pango directory has no CMake file for the package.
For some reason, example code using Pango can still compile (ie: it can find Pango's headers), but it fails to link due to not linking to the right libraries.
So how is this supposed to work? Do I have to list the include directories, library directories, and library files through a variety of CMake interfaces for Pango? Or is there some alternative inclusion mechanism that takes care of the details like most other vcpkg packages?
Note that I'm using Visual Studio 2019's built-in CMake functionality to try to build with these.
find_package finds a particular kind of .cmake file that is usually shipped with vcpkg packages. These .cmake files do the work of setting include directories and libraries to link with.
As such, if a vcpkg package does not include such a file, you will need to essentially do the work that the file would have done. Fortunately, CMake and vcpkg know where the headers and library build files are for the various configurations. What you need to do is find those directories and libraries, then add them to your project (along with any other special compiler options that the package requires, which requires some familiarity with the package).
To find the include directory containing a library's header, use find_path to set a variable, giving it the name of a header file to search for. For example:
find_path(PANGO_INCLUDE_DIR pango/pango.h)
This header directory can then be set as part of the include path:
target_include_directories(project_name_here PRIVATE ${PANGO_INCLUDE_DIR})
Libraries are a bit harder, since you have to track down the full name (minus extensions) of the actual library. And if the package involves multiple libraries, you need to track down all of those which are applicable to you.
Given the name of a library or libraries of interest, you can find them one at a time with find_library, setting those libraries into variables:
find_library(PANGO_LIBRARY pango-1.0)
find_library(PANGOCAIRO_LIBRARY pangocairo-1.0)
You can then link with those libraries via target_link_libraries:
target_link_libraries(cairo_vcpkg PRIVATE
...
${PANGO_LIBRARY}
${PANGOCAIRO_LIBRARY}
)
Indeed, some packages installed via vcpkg do not export a .cmake file like Pango for you and SDL for me.
I want to clarify that I have been trying to use vcpkg for two days, I share with you the cmakelist.txt that I use on my side so that SDL works as if I had used find_package (SDL Required)
cmake_minimum_required(VERSION 3.16)
project(xxxx)
### Specify the C++ standard ###
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/CMake)
### To find and use SDL ###
# find path of include and lib
find_path(SDL_INCLUDE_DIR SDL/SDL.h)
find_library(SDL_LIBRARY SDL)
# find pat of manual-link library
set (LIBRARIES_TO_LINK C:/dev/vcpkg/installed:/x64-windows/lib/manual-link)
find_library(SDL1_TEST SDLmain HINTS ${LIBRARIES_TO_LINK})
....
I recently downloaded goattracker2 on Windows 10 and after making some changes to the source code, I need to recompile the program to test it.
I don't have any experience with recompiling.
I had a look at the documentation included in the readme-file:
Recompiling
To recompile for Win32, you need the MinGW development environment,
use the file src/makefile.win as makefile.
To recompile for Linux, use src/makefile.
In both cases you need the SDL development libraries in addition to
the SDL runtime, see http://www.libsdl.org.
Compile first the utilities (datafile & dat2inc) from the src/bme
directory, and place them to your path.
This leaves me with several questions, like
Which programs do I need to download
How do I run or execute the makefile
Where do I need to install the SDL libraries
If anyone has experience with recompiling goattracker, can they provide a step by step tutorial for how to do it?
Get MinGW (I recommend 32bit version) and install.
Download and unpack the SDL Libraries from https://www.libsdl.org/ (depending on your version you might need SDL 1.x)
The SDL Libraries (the *.a files) have to be added in the lib directory of MinGW installation directory (this might be different from the lib dir of MinGW, see this issue)
The header files from SDL (SDL2/ directory MinGW) have to be put where MinGW can find them (this might be different from the include dir of MinGW, see this issue)
Go to the src directory of goattracker and type make -f makefile.win
I downloaded mosesdecoder and compiled it successfully. Since there were a few boost errors with difference in versions, I installed boost in custom directory. I'm trying to install mgiza with custom boost install now.
In the moses additional resources page: http://www.statmt.org/moses/?n=Moses.ExternalTools, it says:
Compiling MGIZA requires the Boost library. If your Boost library are in non-system directory, use the script
manual-compile/compile.sh
to compile MGIZA.
But simply running it from the mgiza/mgizapp directory gave a lot of file not found errors. I found out that I had to set the SRC_DIR and BOOST_ROOT directories correctly.
Once I set that, the code
But the initial line of the file, and all the subsequent compile files are saved in the $PWD, where I'm compiling the script from.
So which directory should I compile the script from in order to run moses end-to-end smoothly?
UPDATE: I already answered the question. Thanks
I have found the location from which to compile
manual-compile/compile.sh
It is in the
mgiza/mgizapp/bin/
directory.
mgiza/mgizapp/bin$ ../manual-compile/compile.sh
This may be a no-brainer for longtime boost users, but I’m just getting into boost.
I built the full boost distribution and BCP to extract just the parts I need to put in my VisualStudio C++ project.
What I found is when I call bcp, it copies the source tree to the destination. It doesn’t copy the required compiled lib files though (for those modules that need it).
So when I build my project and include
#include "boost/program_options.hpp"
for example, I get a linker error:
*Error 1 error LNK1104: cannot open file 'libboost_program_options-vc100-mt-sgd-1_54.lib'*
So my question is this:
should BCP also copy over the compiled LIB files as necessary ?
or
is it standard procedure for users of BOOST to manually copy those complied library files themselves?
I recently started experimenting with BCP. It seems like any boost modules that require libraries will not be copied, but instead they need to be built using bjam.
For example, when you run bcp on your code it will output some 'INFO' statements like this:
INFO: tracking source dependencies of library date_time due to presence of BOOST_DATE_TIME_DECL...
INFO: tracking source dependencies of library smart_ptr due to presence of "void sp_scalar_constructor_hook...
Notice that in addition to the generated 'boost' folder containing a bunch of copied boost header files there will be a 'libs' folder along with Jam files (Jamroot, Jamfile.v2, etc).
I think you need to cd to the directories with the Jamfiles and use bjam to build the needed libraries.
Maybe this answer will help:
Building a subset of boost in windows
I have been trying to build RPM packages for libc++ 3.3 on a RHEL 6.4 box. I need both static and shared libraries. So, I learned some basics of cmake and then modified the bundled CMakeList.txt. Got that part to work.
But since in RHEL 6.x, all 64-bit libraries should go to /usr/lib64 instead of /usr/lib, I have been attempting to use the following to get the job done:
(A) During building, I use
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX})
to have all library files (*.so* and *.a) located in lib64 rather than lib.
(B) Using a ADD_LIBRARY... command as shown below
ADD_LIBRARY(c++ STATIC ...
together with
set_target_properties(c++ PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX})
INSTALL(TARGETS c++
ARCHIVE DESTINATION lib${LIB_SUFFIX})
to get the static library installed in /usr/lib64.
(C) In addition, with
INSTALL(FILES ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}/libc++.so DESTINATION lib${LIB_SUFFIX})
INSTALL(FILES ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}/libc++.so.1 DESTINATION lib${LIB_SUFFIX})
INSTALL(FILES ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}/libc++.so.1.0 DESTINATION lib${LIB_SUFFIX})
to have shared libary also installed in /usr/lib64 too.
But a copy of the shared library is still installed in /usr/lib in the resulting RPM. How can I prevent it?
If I were to write a RPM spec file, the _libdir macro automatically handles this. With cmake, given the fact that I am still new to it, I would appreciate a hint/pointer as to the right directive to use.
Actually, with a helpful person in the cmake mailing list, I am now able to rid of the %dir /usr/lib in the generated spec file. It's actually quite simple: just cd to $CMAKE_SOURCE_DIR/lib and edit the CMakeLists.txt there. Append ${LIB_SUFFIX} to the two install DESTINATIONs. Regenerate the Makefile in the build subdirectory, and then make && make package. All library files go into /usr/lib64 as desired.
What I can see:
1) There's a missing space in ARCHIVE_OUTPUT_DIRECTORY${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}), should be ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX})
2) When are your .so files going to be build if you use ADD_LIBRARY(c++ STATIC ...?