Last year Boost (from the modular boost git repository) could be built in Windows using these steps.
I got quite far almost a year later, using this recipe:
Install MinGW (32-bits) and Msys (bash etc) using mingw-get-setup
Install the Windows Driver Kit (for W7 I used WDK 7 -- GRMWDK_EN_7600_1.ISO), which provides MASM 8 (needed for boost > 1.51 according to this post)
-downloading the ISO image and extracting the files with WinRAR worked for me
-the installer advises against installing the DSF, so skip that
-add the directories of ML64.exe and ML.exe to the path (both required)
C:\Windows\WinDDK\7600.16385.1\bin\x86\amd64;
C:\Windows\WinDDK\7600.16385.1\bin\x86
Install a 64/32-bit compiler as well (I used TDM gcc 5.1.0-2) and add its bin/ directory to the Windows path
open cmd.exe as administrator and start bash
in the parent dir of boost, run
git clone --recursive https://github.com/boostorg/boost.git boost > clone.log
exit bash, goto directory boost and run:
bootstrap gcc
in project-config.jam, change using msvc ; into using gcc ;
run:
b2 headers (now needed to make symbolic links)
b2 -a -d+2 -q --build-type=complete --build-dir=build toolset=gcc link=shared runtime-link=shared threading=multi
These options to b2 worked with previous versions of boost, but now I can only compile with b2 without options. The full command line returns these errors: undefined reference to __imp_make_fcontext and undefined reference to __imp_jump_fcontext.
I cannot find other posts or even web pages that describe these errors. Does anyone know a way in Windows to still use the b2 options for the latest boost from the GitHub repository?
EDIT:
Using b2 -a -d+2 -q --build-dir=build toolset=gcc works. Apparently the --build-type=complete option is the first of the ones above to break the compilation.
The flags link=shared, runtime-link=shared and threading=multi also cause b2 to stop.
Has anyone got a clue how to solve this? is there a patch for MinGW that works for the current repositories?
Your best bet may be switching to MSYS2 which is a new and improved version of MSYS. I have very good experience with MSYS2 whereas I can't say that about MSYS or Cygwin (In my case that's building a project heavily using boost and c++11).
You can read some comparison here.
Also taken from the answer here:
While MSYS isn't dead, I would say it's not looking very healthy either.
Related
I can not find 'libboost_filesystem-vc141-mt-sgd-x32-1_69.lib' of boost (tried building it myself and also downloaded the binaries for vs141 and x32 from https://sourceforge.net/projects/boost/files/boost-binaries/1.69.0/)
what I have is
libboost_filesystem-vc141-mt-gd-x32-1_69.lib from the downloaded binaries
and
libboost_filesystem-vc141-mt-s-x32-1_69.lib that I built myself
where can I find this file?
thanks
It seems you want the -s in the build. From this, you would use link=static and runtime-link=static. I have not tried that. But I know it will build this version if you --build-type=complete on the b2 command line. And, it is just as well you build your own to keep compiler/SDK version conflicts out of your work.
Lots of information on b2 here.
I am on Ubuntu 14.04.3 platform. While I was compiling a project it asked cmake version 3.2 which is not present in my system. I compiled the latest version of cmake from source code and installed it into /usr/local/bin directory. When I attempt to compile project again, its cmake detects the cmake in /usr/bin which is lower version. Then cmake ..
process aborts with lower version error. Is there any built-in cmake variable or environment variable for setting path of the cmake?
EDIT:
I just found a cmake variable CMAKE_COMMAND that supposedly does what I want.
But when I insert CMAKE_COMMAND = /usr/local/bin/cmake line into cmakelist.txt then I go to build directory and issue /usr/local/bin/cmake ..
I get :
Expected a command name, got unquoted argument with text
I searched for it on the net but didn't find a solution.
If you have different versions of a software or library installed you may use stow to install and switch between the two. Especially if you want to install a newer version of a software that is not available in one's Linux distribution. So in case the new version is not yet stable you can still switch to the previous one. For example while building cmake 3.2 you can specify the prefix as
./configure --prefix=/usr/local/stow/cmake-3.2/
and then
cd /usr/local/stow
sudo stow cmake-3.2
and if you want to remove the links you can use the following command
sudo stow --delete cmake-3.2
Please keep in mind stow does not delete files. It only makes and deletes links.
I've been trying this for over 5 days and I have no idea how to get this to work. I had successfully installed boost once, then I got my computer re-imaged and now it's just not happening. I have Windows 7 Enterprise, and 64-bit operating system.
I downloaded boost from here sourceforge
unzipped it into program files.
I then went to the VS 2013 Native Command prompt. Changed directory to boost tools/build
Ran bootstrap.bat
I then ran ./b2 address-model=64
but it did not give me directories for the compiler and the linker like last time.
I then ran ./b2 --prefix=C:\ProgramFiles\boost_1_58_0
but again nothing happens. I get the following errors:
Warning: No Toolsets were configured.
Warning: Configuring default toolset ""msvc"
Warning: If the default is wrong, your build may not work correctly
warning: Use the "toolset=xxxxx" option to overrride out guess
warning: for more configuration please consult
I have no idea why this worked the first time I had done this and why this isn't working now. Can someone please help me out. I know nothing about Unix but I need to install this so I can use the libraries.
I compile boost with both mingw (64 bit) and msvc 2013 pro. I have never in my life used the vs command prompt to build boost with msvc. Here are my commands to build 64 bit binaries on both toolchains.
First go into the boost folder and just double click bootstrap.bat. This should run and build bjam/b2. Nothing special required and doesn't matter what compiler this gets built with.
Then simply run, in a normal command prompt:
bjam.exe -a -j8 --toolset=msvc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\MSVC-X64 release stage
Where -a forces rebuild all, -j8 means for the build to use 8 cores (adjust this based on your processor capabilities), toolset is obvious, layout means how to structure the naming of the output files, address-model is obvious, stagedir is where to output the built binaries (either relative or absolute path) and release stage is the type of build the system. See more here.
Same thing but using 64 bit mingw.
bjam.exe -j8 --toolset=gcc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\x64 release stage
You can even go on to build additional libraries with a second pass tweaking your arguments. For example, after I've built the core libs with the above command, I run the following command to build in zlib and gzip support.
bjam.exe -a -j8 --toolset=msvc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\MSVC-X64 --with-iostreams -s BZIP2_SOURCE=C:\dev\libraries\cpp\bzip2-1.0.6 -s ZLIB_SOURCE=C:\dev\libraries\cpp\zlib-1.2.8 release stage
Anyway that's just as an example. I linked to the full docs for the build system. Try building using these commands NOT inside a vs command prompt. If you still have problems then please post specific errors.
A note about MSVC
So, msvc compiler + boost supports a type of linking where it will automatically include additional libraries that it knows it needs. I believe boost does this by using the #pragma directive in headers. For example you might use boost::asio configured in such a way that it needs boost::system (for error codes and such). Even if you don't explicitly add boost::system library to the linker options, msvc will "figure out" that it needs this library and automatically try to link against it.
Now an issue arises here because you're using layout=system. The libraries are named simply "boost_" + the lib name, like "boost_system.dll". However, unless you specify a preprocessor define, this auto linking will try and link to a name like "boost_system_msvc_mt_1_58.lib". That's not exact as I can't recall the exact name, but you get the idea. You specifically told boost to name your libraries with the system layout (boost_thread, boost_system) etc instead of the default, which includes the boost version, "MT" if multithreaded, the compiler version, and lots of other stuff in the name. So that's why the auto linking feature goes looking for such a crazy weird name and fails. To fix this, add "BOOST_AUTO_LINK_NOMANGLE" in the Preprocessor section of your C++ settings in visual studio.
More on that here. Note that the answer here gives you a different preprocessor definition to solve this problem. I believe I ended up using BOOST_AUTO_LINK_NOMANGLE instead (which ended up working for me) because the ALL_DYN_LINK macro turned out to be designed as an "internal" define that boost controls and sets itself. Not sure as it's been some time since I had this issue, but the define I provide seems to solve the same root issue anyway.
I tried to build the Boost library for native 64bit using MinGW64 compiler, but got some failures. Any pointers are appreciated. Thanks.
I got the bjam.exe (b2.exe) compiled in 64bit (with warning) and I used it the get the Boost built. I got the following error when building Boost.Context. (I wrote the command in batch for repeatable building). Anything I missed?
Command: b2.exe install --prefix=%~dp0\bld\Boost.Build
Error: 'ml64' is not recognized as an internal or external command, operable program or batch file.
I read the documentation and it said:
Boost.Context must be built for the particular compiler(s) and CPU architecture(s)s being targeted. Boost.Context includes assembly code and, therefore, requires GNU AS for supported POSIX systems, and MASM for Windows systems.
So, is it possible to tell the bjam to use the as.exe included in my MinGW installation?
(As I have multiple MinGW, the location is not standard as C:\MinGW\bin)
project-config.jam
import option ;
using gcc ;
option.set keep-going : false ;
Platform
Windows 7 x64
Boost 1.52.0 (source from sourceforge)
MinGW 4.7.2 (rubenvb x64)
No MSVC installation (no ml64.exe installed/found in my machine)
Edit Problems occurred when installing WDK
Warning when building BJam, I think it can be ignored
function.c: In function 'check_alignment':
function.c:222:5: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
Full batch
SET OPATH=%PATH%
SET BOOST_VER=boost_1_52_0
SET "PATH_ZIP=C:\Program Files\7-zip"
SET "PATH_MINGW=C:\MinGW\rubenvb-4.7.2-64"
SET "PATH_SRC=%~dp0\%BOOST_VER%"
SET "PATH_BJAM=%PATH_SRC%\tools\build\v2\engine"
TITLE Extracting Packages ...
IF NOT EXIST "%PATH_SRC%.7z" GOTO :err_nozip
RD /S /Q "%PATH_SRC%"
"%PATH_ZIP%"\7z x "%PATH_SRC%.7z"
TITLE Building BJam ...
PUSHD "%PATH_BJAM%"
SET "PATH=%PATH_MINGW%\bin"
SET "BOOST_JAM_TOOLSET_ROOT=%PATH_MINGW%\"
CALL build.bat mingw --show-locate-target
SET PATH=%OPATH%
COPY "bin.ntx86_64\b2.exe" "%PATH_SRC%\" > nul
COPY "bin.ntx86_64\bjam.exe" "%PATH_SRC%\" > nul
POPD
TITLE Installing Boost Build...
PUSHD "%PATH_SRC%"
ECHO import option ; > project-config.jam
ECHO. >> project-config.jam
ECHO using gcc ; >> project-config.jam
ECHO. >> project-config.jam
ECHO option.set keep-going : false ; >> project-config.jam
ECHO. >> project-config.jam
b2.exe install --prefix=%~dp0\bld\Boost.Build
POPD
SET PATH=%OPATH%
This is a known issue for building Boost >~1.51 with MinGW. At the moment, building Boost with MinGW is broken because Boost has a dependency on MASM (in your case ml64) when building Boost::Context for Windows, even with MinGW.
As a bodge you can get MASM from the Microsoft Website: http://www.microsoft.com/en-gb/download/details.aspx?id=12654 for a 32-bit version, or else the Windows Driver Kit for the 64-bit version: http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx
You can use the patch provided on the Boost bug tracker here: https://svn.boost.org/trac/boost/ticket/7262 though to make Boost::Context compile with just MinGW, thus re-enabling cross-compilation of Boost. You can also read the responses by Boost's Olli on the subject and his response to the subject. Don't expect anything to be fixed in Boost for a while at least!
Posting this answer here for the benefit of Google, because I've been struggling with this problem all day, and finally found a solution.
Boost context will fail to link under MinGW if built with MASM 6, because it produces the EXPORT symbol.
This manifests as undefined reference to `make_fcontext' even though the library is linked correctly.
Objdump on the resulting library gives make_i386_ms_pe_masm.o: File format not recognized.
The solution is to make sure you're using MASM 8.
You can download it at http://www.microsoft.com/en-us/download/confirmation.aspx?id=12654 - the installer will bitch about needing to have VC installed, but you can just bypass this by extracting the contents of the installer using a tool such as WinRAR; extract setup.exe and extract again to get a .cab, and extract a third time and rename the resulting binary file to ml.exe.
Then rebuild Boost with bjam --toolset=gcc --with-context -a stage.
Hopefully someone googling the same terms I've been googling all day will find this helpful.
According to Boost's requirements, you can find MASM64 in Microsoft's Windows Driver Kit (WDK).
I downloaded WDK 7 from Microsoft Download Center, and after installing it, I found ml64.exe in bin\x86\amd64. With that, I was able to successfully compile Boost 1.53.0.
(If this is relevant still) This happens when your build folders have msvc artifacts left in there. I'm assuming your project-config.jam was initially
import option ;
using msvc ;
and you had built for msvc then changed to "using gcc" In that case you need to issue the following first
bjam --clean
which should clear the artifacts from msvc build and then you can issue and things should be fine
bjam toolset=gcc variant=..... and so on and on
by the way I saw you writing you had Windows 7 x64. your bjam command needs to have adress-model=64 otherwise 32bit binaries will be produced...
A bit late maybe but I managed to compile boost-modular (the Git repository, so should be similar to 1.55 as of July 2014) on Windows 7, using MinGW and the WDK 7.
The steps I used were
install MinGW and Msys (bash etc) using mingw-get-setup (the easy way), add bin/ to path
install the Windows Driver Kit (for W7 I used WDK 7) -- GRMWDK_EN_7600_1.ISO
downloading the ISO image and extracting the files with WinRAR worked for me
the installer advises against installing the DSF, so skip that
add the directories of ML64.exe and ML.exe to the path (both required AFAIK)
C:\Windows\WinDDK\7600.16385.1\bin\x86\amd64;C:\Windows\WinDDK\7600.16385.1\bin\x86
open cmd.exe as administrator and start bash
in the parent dir of boost, run
git clone --recursive https://github.com/boostorg/boost.git boost > clone.log
exit bash, goto directory boost and run: bootstrap gcc
if that finishes w/o problems (if ML64.exe is found), run
b2 -a -d+2 -q --build-type=complete --build-dir=build toolset=gcc link=shared runtime-link=shared threading=multi
Without explicitly adding the ML(64) directories to the path, I still got the errors about ML.
Installing MASM is not the same as installing MSVC. I tried using different assemblers first but boost is not compatibe with their output.
the basic idea was, I wanted to generate the call graph in text format for several c files. After googling around for long time, i found cflow, which can deliver everything I want, but it is only runable in Linux or else. Then I began to search how to compile the cflow source files on the web to a exe file. I found MinGW which should be able to do the cross-platform compilation.
After installing the MinGW and the MSYS and running the usual commands "./configure; make; make install", I simply got an error that "mkdir" was not found. Actually. Actually I was wondering whether this is the correct way to compile the whole package.
Does anyone has an idea how I can build the cflow.exe correctly in Windows? If there is a tutorial or something like this, I will be very thankful.
Song
Solution
Please try this Github repository "MinGW + MSYS build of GNU cflow 1.4" (For Windows).
https://github.com/noahp/cflow-mingw
It contains already compiled "cflow.exe",and an instruction about how to build cflow using mingw and msys.
Test
System Environment:Win 8.1 (x64)
1.I tested the "cflow.exe" downloaded from the github repository , and amazingly it worked!
2.I followed the mingw compiling instruction,and it successfully compiled "cflow 1.5".
Command:
bash configure
make
I was able to do that today. I'm using cygwin, after installing gcc, binutils, make and after downloading the gnu cflow.tar.gz, it was as easy as ./configure ; make ; make install.