I am trying to compile the Boost library for Windows (as a prerequisite for building the Bitcoin client), using the MinGW compiler toolchain to do so (rather than Visual Studio) and running into errors.
Following various guides online, I have a working bjam application, and the boost_1_55_0 source files. I have tried in the windows shell doing:
path/to/bjam.exe toolset=gcc --build-type=complete stage (the instructions that Bitcoin provides), but get mingw.jam: No such file or directory errors
bootstrap mingw from a standard DOS shell runs successfully, but the .\b2 after emits a bunch of 'cl' is not recognized as an internal or external command, operable program or batch file errors, implying it's not really set up to use gcc/mingw, since it's calling for the Microsoft compiler.
bootstrap.sh --with-toolset=mingw from the MSYS prompt (as suggested here, which creates a log file that doesn't have as many errors, but running ./b2 after leads to a mingw.jam no such file error, and mingw.init unknown error.
Downloading the compiled binaries from http://sourceforge.net/projects/boost/files/boost-binaries/1.55.0/ (boost_1_55_0-msvc-12.0-64.exe). After extracting and referring to the lib and header files, compiling the final executable throws a whole bunch of undefined reference to 'boost::system::generic_category()' for various boost features, implying to me the library files aren't actually containing the proper definitions? Is that because they're Visual Studio libraries?
Downloading the archives from http://www.boost.org/users/history/version_1_55_0.html (boost_1_55_0.7z), which the documentation implies comes with a pre-compiled lib dir, but does not in fact.
So, I'm banging my head on several walls at once. Can anyone help me get past any of these roadblocks?
I used the following steps to successfully build boost version 1.54 in a MinGW/MSYS environment:
Build bjam.exe and b2.exe:
boost_1_54_0\tools\build\v2\engine>build.bat mingw
Copy build tools to the root-directory:
cp boost_1_54_0\tools\build\v2\engine\bin.ntx86\*.exe boost_1_54_0
Run bjam.exe:
bjam --toolset=gcc --build -type=complete install > boost_build.log
I used this process with slight variations for various boost versions, so its a good guess it will work for 1.55 too
Related
So I get a bit confused on the many possibilities here. I have a CMakeLists.txt, which is hopefully all ready to be used. I am using WSL in the Windows Terminal and switching between microsofts cmd.exe and ubuntu wsl terminal on which I want to be able to run the compile command. So on which side do I need to run cmake and what build-files should I generate or what compiler should I use?
Main goal is having a simple compile cmd in vim on wsl, that compiles the exe for windows.
I tried to setup the build files with cmake from the wsl-side with the mingw cross-compiler, but during project setup it failed to find glfw3 configurations, which felt rather weird since it should use windows glfw files anways, right(?)
Next closest try was to create the build files with cmake from the cmd-site with the cl.exe compiler and ninja. That succeeded, but when now running ninja on the wsl side I get a lot of warnings concerning the unknown cmd option \O0 and fatal errors concerning not being able to include simple files like float.h, stdio.h, Windows.h etc. .
All my current search led me to this point, but I am not able to come up with a solution. So I would love to get some help. I want to stick mainly on the linux side, when programming but in the end have an executable for windows.
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.
I've successfully built a demo app using opencv on windows with the MSYS shell environment.
I did NOT use the prebuilt opencv installer, I downloaded and compiled the source locally (this is the recommended method).
After building opencv and running make install, all the files are happily in:
/e/deps/libopencv/build/install/
I can successfully build a sample application against this using cmake directives along the lines of:
find_package(OPENCV REQUIRED)
link_directory(${OpenCV_LIB_DIR})
include_directories(${OpenCV_INCLUDE_DIRS})
target_link_libraries(target ${OpenCV_LIBS})
To be completely clear here: building the binary is successful.
Now, when I run it from the shell I get the message:
The program can't start because libopencv_core231.dll is missing from your computer.
Try reinstalling the program to fix this problem.
So... I know where the libraries are:
$ ls /e/deps/libopencv/build/install/lib/
libopencv_calib3d231.dll.a libopencv_features2d231.dll.a libopencv_highgui231.dll.a libopencv_ml231.dll.a libopencv_video231.dll.a
libopencv_contrib231.dll.a libopencv_flann231.dll.a libopencv_imgproc231.dll.a libopencv_objdetect231.dll.a
libopencv_core231.dll.a libopencv_gpu231.dll.a libopencv_legacy231.dll.a libopencv_ts231.a
What now?
I guess I could try to make cmake build a static binary, but that seems pretty extreme.
How can I somehow make either 1) windows, or 2) the MSYS environment happy. Something like LD_LIBRARY_PATH on windows?
Or is this not the problem, and I've actually (despite appearances) somehow messed up the way the binary was compiled?
Edit:
NB. For whatever reason it seems that my libraries are .dll.a files, not .dlls (see the ls result) if that's remotely relevant.
windows searches the same directory as the exe, any directory in the %PATH% (Windows) or $PATH (msys) directories, as well as a few special ones in the windows folder
You could add /e/deps/libopencv/build/install/lib to your $PATH. I am not sure if this will work for msys, you may need to add E:\deps\libopencv\build\install\lib to %PATH% in windows instead.
The typical solution for this if you are giving the program to others is to include a copy of the DLL in the same directory as the EXE. you can get this same effect by making a symbolic link to it with the command
ln -s /e/deps/libopencv/build/install/lib/libopencv_core231.dll libopencv_core231.dll
while in the /e/deps/libopencv/build/install/ directory
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.