I am trying to build libtorrent (http://www.libtorrent.org/) using the provided jamfile. If I try to build it in its vanilla state everything goes well. I am then building using this command:
bjam msvc-12.0 boost=source
However I want to build it with OpenSSL which there seem to be support for. This is where I run into problems. Most likely because it is the first time I use Bjam (actually anything else than make files). I now try to run the following command:
bjam msvc-12.0 boost=source encryption=openssl
Now the compiler starts to complain about not finding the OpenSSL include files.
So I guess I have to include this path in the JAM file. But I have no idea where.
I also tried to add the path into the INCLUDE environment varaible in windows but that doesn't seem to be picked up by BJAM or msvc. Any suggestions?
My understanding of how this is normally done on windows is by installing libraries and headers into visual studio's include and lib folders.
(That's how I install openssl on windows at least).
The jamfile is also supposed to pick up CXXFLAGS and LDFLAGS environment variables, which you could use to introduce the library- and include paths. However, it only does this when boost=system is specified, i.e. you're building against "system" boost libraries instead of from source.
Related
So basically I have the following setup:
A small test library called mylib with an according CMake file. The CMake file creates all the necessary information so that another project (which is going to be my binary) can use find_package to add the library. The library also has a install target.
A small binary called mybin again wih according CMake file which is depended on the mylib project. Using find_package I can add mylib either by specifying the location of the according myLibConfig.cmake (and myLibTargets.cmake etc.) files or by executing the install target of mylib and then letting CMake find the library itself.
Using CMake and XCode everything works like a charm. First, I configure and build the library. Second, I configure my binary project, specify the location of the library and then build it without any problems.
Now I want to do the same using CLion. My problem now is that CLion puts all the generated CMake file (which usually are placed in the build folder) in some cryptic location which can't be changed in the IDE. Now, when I want to build the mybin project I have to specify this cryptic location which seems kinda odd to me (especially because you have to find out first where CLion actually places those files).
So my question is: Is there a more convenient way to handle the described configuration? I guess this is more or less the standard use case which makes me wonder if I'm missing out on something. Being able to specify where CLion should put the generated CMake files would solve my problem I guess.
I know that i can install the library (using the install target) and then let CMake find it. The problem here is that CLion (to my understanding) doesn't support install targets and therefore I have to use (in my case) XCode to build and install the library first.
I was misunderstsanding the intention of find_package(as Tsyvarev pointed out). By using the solution proposed in this question I managed to add an install target to CLion which now allows me to conveniently build "mylib" and use it in the "mybin" project without having to configure anything manually.
While trying to build the thrift c++ library, I came across the following error after specifying the --with-boost option.
If you have a staged boost library (still not installed) please
specify $BOOST_ROOT in your environment and do not give a PATH to
--with-boost option.
I looked through the boost documentation (which is I am not overly familiar with), but I did not find a good definition for the term staged boost library. I see the parenthetical (still not installed), but there are many states that are a library can be in that fall under the category of not installed.
When I first download boost, I run ./bootstrap and ./b2 to compile it.
Is it staged at this point? Or do I have to do something else to make it staged?
You can call
b2 --help
to see options of Boost.Build, and there you can find
install Install headers and compiled library files to the
======= configured locations (below).
...
stage Build and install only compiled library files to the
===== stage directory.
The declaration of stage or install specifies whether the Boost Libraries are installed in a subfolder named stage or system-wide. The meaning of system-wide depends on the operating system. In Windows, the target directory is c:\boost, in Linux it is /usr/local. The target directory can also be explicitly specified using the -–prefix option. Also see this answer, I guess it will be helpful.
For more informations see Getting Started Guide for Windows or Linux.
When you run .\b2 to compile Boost, it create a folder called stage and output of the compilation is put inside %BOOST_ROOT%\stage\lib folder. Now you can copy this lib folder somewhere and add that in to linker's path. However some projects might expect binaries to be available at stage\lib. So "staged" here means if you have libraries compiled and present in stage\lib folder. The .b2 command takes several different parameters to compile different kids of binaries, for example, below compiles binaries that are linked to shared runtime and targeting x64 architecture:
b2 variant=debug,release link=shared runtime-link=shared address-model=64
Each variant of lib file name has tags so they don't overwrite each other, for example, libboost_date_time-vc140-mt-gd-1_62.lib.
I'm compiling boost with bjam under Windows 7 (64bit-should be irrelevant)
D:\development\boost\boost_1_44\libs\iostreams\build>bjam stage ^
--toolset=msvc-10.0 link=static ^
--build-type=complete ^
-s ZLIB_SOURCE=C:\zlib125-dll ^
-s ZLIB_LIBPATH=C:\zlib125-dll\lib ^
-s ZLIB_INCLUDE=C:\zlib125-dll\include ^
-s ZLIB_BINARY=C:\zlib125-dll
But I only get
stage/libboost_iostreams-vc100-mt-gd-1_44.lib
bin.v2/libs/iostreams/build/msvc-10.0/debug/threading-multi/boost_iostreams-vc100-mt-gd-1_44.dll
bin.v2/libs/iostreams/build/msvc-10.0/debug/threading-multi/boost_iostreams-vc100-mt-gd-1_44.lib
bin.v2/libs/iostreams/build/zlib/msvc-10.0/debug/threading-multi/boost_zlib-vc100-mt-gd-1_44.dll
bin.v2/libs/iostreams/build/zlib/msvc-10.0/debug/threading-multi/boost_zlib-vc100-mt-gd-1_44.lib
but stage/libboost_zlib-vc100-mt-gd-1_44.lib is missing.
Am I compiling something wrong?
when I try running my project that worked well with boost and self-compiled boost/thread libraries I get the following error when I include the boost zlib stuff
6>LINK : fatal error LNK1104: cannot open file 'libboost_zlib-vc100-mt-gd-1_44.lib'
Does anyone know what I'm doing wrong?
I did manage to build them using the option
-sZLIB_SOURCE="C:\zlib-1.2.5"
Note there is no space after the -s and the quotes around the path.
It took me a while to get Boost to build correctly with zlib support.
The problem I ran into was that at some point zlib no longer included a gzio.c source file. The jamfile for the Boost build system (jamfile.v2) had a reference to the gzio module which caused it fail. The solution was to remove that reference before building.
I'm not sure this answer is relevant any longer, unless you're trying to build an old version of Boost. I believe the original build issue has been fixed in more recent versions of Boost.
I had the same problem (Windows 7 Visual Studio) and I believe the issue is not in how you build boost.
1) As ecotax, there should not be a space after the -s
2) When running bjam, add the flag --debug-configuration. If in the output you do not see errors and it prints out something like
notice: iostreams: using prebuilt zlib
then it has found your zlib copy, which it is good.
3) Notice that the library libboost_zlib-vc100-mt-gd-1_44.lib should not be produced.
4) When you compile your application in Visual Studio, seems that Boost.Iostreams auto-linking still wants libboost_zlib-vc100-mt-gd-1_44.lib and reports a link error.
What it worked for me (I founded googling) was to add to the preprocessor definitions the flag
BOOST_IOSTREAMS_NO_LIB
I was trying all sorts of things and had a hard time finding the correct solution for newer versions of boost (1.75.0).
All the -sZLIB_xxx switches seem to be not working anymore.
Boost Documentation just states
On Windows the zlib, bzip2, zstd and/or LZMA binaries need to be in the PATH, else they will not ordinarily be found by default, so it is always a good idea under Windows to setup the zlib, bzip2, zstd and/or LZMA toolsets in your own jamfile.
Setting path did not lead to any success, so I dig through more documentation. Boost provided jam documentation and examples are not the most helpful, so through analysis of the Conan Recipe for the Conan boost package I finally came up with this minimal user-config.jam file that does the trick for me:
using zlib : your.zlib.version :
<include>"path/to/zlib/include/headers"
<search>"path/to/zlib/library/file" ;
The minimal b2 command to execute this for me is:
.\b2.exe --user-config="path/to/user-config.jam"
Hope this can be of help to others so they don't need to waste a lot of time as I did.
For guys, who compiling, using prebuilt 'zlib'.
These steps needs to be done:
Download and build 'zlib'
Run b2.exe --with-iostreams -s ZLIB_BINARY=zlib -s ZLIB_INCLUDE=C:/Sys/zlib-1.2.7/Include -s ZLIB_LIBPATH=C:/Sys/zlib-1.2.7/Lib release
Update paths to your local installation zlib folder. This way, Boost will embed into libboost_iostreams the gzip.cpp, zlib.cpp files. No libboost_zlib will be generated.
At your source file add this lines (somewhere in stdafx.h, before including Boost.Iostream headers):
--
#ifdef _DEBUG
#define BOOST_ZLIB_BINARY zlibd
#else
#define BOOST_ZLIB_BINARY zlib
#endif
This tells that you don't want to link against libboost_zlib, but you provide precompiled zlib library instead.
At your project settings provide path to zlib.lib file.
It should compile and link now.
I took a combination of advice from other answers here and this is what I did:
Extract zlib to C:\zlib\zlib-1.2.11.
Use CMake to configure and generate MS Visual Studio 2017 project and use MS Visual Studio 2017 to build the project. I built it in place so that C:\zlib\zlib-1.2.11 now contains (in addition to previous contents) directories lib and include.
Extract Boost 1.67.0 to C:\Boost\boost_1_67_0.
(Be on drive C:)
cd \Boost\boost_1_67_0
bootstrap.bat
set ZLIB_SOURCE="C:\zlib\zlib-1.2.11"
set ZLIB_INCLUDE="C:\zlib\zlib-1.2.11\include"
set ZLIB_LIBPATH="C:\zlib\zlib-1.2.11\lib"
The following line built libboost_iostreams and it did put libboost_zlib files in C:\Boost\boost_1_67_0\stage\lib:
b2 --debug-configuration --with-iostreams -sZLIB_SOURCE="C:\zlib\zlib-1.2.11" -sZLIB_INCLUDE="C:\zlib\zlib-1.2.11\include" -sZLIB_LIBPATH="C:\zlib\zlib-1.2.11\lib"
The following line built the rest of Boost:
b2 -sZLIB_SOURCE="C:\zlib\zlib-1.2.11" -sZLIB_INCLUDE="C:\zlib\zlib-1.2.11\include" -sZLIB_LIBPATH="C:\zlib\zlib-1.2.11\lib"
Don't know if this is the most optimal way to do it, but it did build the libboost_zlib lib files.
set ZLIB_SOURCE="c:\zlib"
set ZLIB_INCLUDE="c:\zlib"
.\b2
.\bjam will not build but .\b2 will build the library: stage/libboost_zlib-vc100-mt-gd-1_44.lib
I can't find a pre-built set of MSVC++ libs for Boost 1.37.0, only the source. I don't understand how their weird build system works... are there any places I can find a download of a visual studio project or something?
The BoostPro Computing folks maintain the Boost installer for Windows but it usually take a few weeks for them to put new versions online. It's not yet up for 1.37.
There's no Visual Studio solution (remember, Boost targets many platforms) though there is an effort to also support building Boost with CMake. I'm not sure how far along they got for 1.37 but I believe it's still early days for this process.
However the standard build system isn't that weird! Start by downloading bjam for your platform (look for a suffix of 'ntx86' for Windows) and installing it somewhere in your path (C:/Windows/System32). Then download the source, uncompress it and run the build system from the command line. It'll look something like this for Visual Studio users:
bjam --build-dir="C:\boostsource" --toolset=msvc --build-type=complete stage
This is lifted pretty much from the Getting Started Guide which goes into much more detail. The build-dir is not needed if you're current directory is the root of the source.
After waiting a couple of hours for everything to build ('complete' means that it'll build debug, release, single/multi threaded, static/dynamic, static/dynamic linking to the runtimes - and combinations) you'll end up with all of the libs in a 'stage/lib' directory.
Finally you need to tell Visual Studio where to find the headers and libs. Go to Tools->Options->Projects and Solutions->VC++ Directories. Add an entry for "Include files" (like "C:\boostsource"). Add an entry for "Library files" ("C:\boostsource\stage\lib").
I've got a build of 1.37 (VC 7.1, 8, 9) on my website, help yourself.
http://boost.teeks99.com/
(Update... 1.38 is up there as well)
(Another Update, 1.39 is now there)
(1.40 is up)
(1.41 is up, a bit late)
It seems complicated, but building Boost is really not that bad. First you need to download the bjam tool (SourceForge is a good source). Make sure bjam.exe is in a directory in your PATH.
Go the the root of your unzipped Boost download (e.g. C:\Boost_1_37_0)
Type bjam --help to get a list of all your build options.
I use the following command to build everything, you can customize it to suit your needs:
bjam --prefix=C:\boost --build-dir=C:\build --build-type=complete install
The results will be placed in C:\boost and you can delete C:\build.
Building it isn't difficult.
They have a fairly good expanaltion of the default process here:
http://www.boost.org/doc/libs/1_37_0/more/getting_started/windows.html#or-build-binaries-from-source
Download bjam (from sourceforge, there are links from the boost website), as well as the boost sources, make sure bjam is accessible from the boost dir, cd to the boost dir, and run something like the following:
bjam --build-dir= --prefix-dir= --toolset=msvc --build-type=complete install
where is an temp dir where it can store intermediate files, and is the final install location. There are all sorts of other options you can play around with, and not all of them are documented very well, but the basics are fairly simple.
For more help, you can run bjam --help from the boost source dir.
My development shop has put together a fairly useful Python-based test suite, and we'd like to test some Linux-based C++ code with it. We've gotten the test project they ship with Boost to compile (type 'bjam' in the directory and it works), but we're having issues with our actual project.
Building the boost libraries and bjam from source (v1.35.0), when I run bjam I get a .so in the bin/gcc-4.1.2/debug directory. I run python and "import " and I get:
ImportError: libboost_python-gcc41-d-1_35.so.1.35.0: cannot open shared object file: No such file or directory
Looking in the library directory, I have the following:
libboost_python-gcc41-mt-1_35.so libboost_python-gcc41-mt-1_35.so.1.35.0 libboost_python-gcc41-mt.so
Obviously I need the -d instead of the -mt libraries, or to point at the -mt libraries instead of -d, but I can't figure out how to make my Jamroot file do that.
When I install Debian Etch's versions of the libraries, I get "No Jamfile in /usr/include" - and there's a debian bug that says they left out the system-level jamfile.
I'm more hopeful about getting it working from source, so if anyone has any suggestions to resolve the library issues, I'd like to hear them.
Response to answer 1: Thanks for the tip. So, do you know how I'd go about getting it to use the MT libraries instead? It appears to be more of a problem with bjam or the Jamfile I am using thinking I am in debug mode, even though I can't find any flags for that. While I know how to include specific libraries in a call to GCC, I don't see a way to configure that from the Boost end.
If you want to build the debug variants of the boost libraries as well, you have to invoke bjam with the option --build-type=complete.
On Debian, you get the debug Python interpreter in the python2.x-dbg packages. Debug builds of the Boost libraries are in libboost1.xy-dbg, if you want to use the system Boost.
Found the solution! Boost builds a debug build by default. Typing "bjam release" builds the release configuration. (This isn't listed in any documentation anywhere, as far as I can tell.) Note that this is not the same as changing your build-type to release, as that doesn't build a release configuration. Doing a 'complete' build as Torsten suggests also does not stop it from building only a debug version.
It's also worth noting that the -d libraries were in <boost-version>/bin.v2/libs/python/build/<gcc version>/debug/ and the release libraries were in <gcc-version>/release, and not installed into the top-level 'libs' directory.
Thanks for the other suggestions!
One important Point: -d means debug of course, and should only be linked to a debug build of your project and can only be used with a debug build of python (OR NOT, SEE BELOW). If you try to link a debug lib to a non-debug build, or you try to import a debug pyd into a non-debug python, bad things will happen.
mt means multi-threaded and is orthogonal to d. You probably want to use a mt non-d for your project.
I am afraid I don't know how to tell gcc what to link against (I have been using Visual Studio). One thing to try:
man gcc
Somewhere that should tell you how to force specific libs on the linker.
EDIT: Actually you can import a debug version of you project into a non-debug build of python. Wherever you included python.h, include boost/python/detail/wrap_python.hpp instead.